GeezerVison is showing github.com — Generic meta types · Issue #3779 · microsoft/TypeScript
DescriptionAs far as I know, in Flow there are so called "generic meta types" that can operate on other types:
type C = $Merge<{a: number}, {b: string}>; // C = { a: number, b: string }
type A = $Args<(a: number, b: string) => void>; // A = [number, string]Such "type algebra" would be useful to construct function signatures and interfaces that are hard/impossible to construct with other techniques:
interface TaggedFunction<Callable extends (...args) => any> {
type Args = $Args<Callable>;
type RetV = $RetV<Callable>;
(...args: ...Args): RetV;
tag: number;
bind<...T>(...args: ...T): TaggedFunction<(...args: $Concat<Args, ...T>) => RetV>;
}Do you think this would be a useful addition to the type system? ActivityLenne231 commented on Jul 8, 2015 I like the idea, but maybe this can also be solved with type providers (#3136). This would be way more flexible. danquirk commented on Jul 8, 2015 It seems like $Merge would be better described through intersection types:
// & not checked in yet but you can use | here to see how it works with unions
type c = typeof a & typeof b; $Args and $RetV look like they're essentially compile time reflection APIs. d180cf commented on Jul 9, 2015 Some of these meta types can have corresponding meta operators: & can denote $Merge, + can denote $Concat and so on; while other meta types, like $Args, won't have a corresponding operator. Such operators will essentially allow to write expressions that operate on types and construct other types.
Lennart (@Lenne231), I'm not familiar with type providers, but a brief look at #3136 made me think that it's an imperative/procedural way of constructing types at compile time, while what I'm suggesting is a declarative way. If this is the case, then type providers is indeed a much more powerful feature. d180cf commented on Jul 23, 2015 Btw, does TS have plans to support nested types: interface Foo { type Bar = number; }? If yes, then it seems natural to have built-in nested types:
interface DecoratedFunction<F extends (...args) => any> {
(...args): F.ReturnValueType;
tag: number;
}danquirk commented on Jul 23, 2015 d180cf local/nested types are already in, planned for 1.6: #3266 Lenne231 commented on Jul 27, 2015 A "generic meta type" that creates a subset would also be nice, especially for functions that update data.
type A = $Sub<{ a: number; b: string }>; // A = { a?: number; b?: string }
function setState<T>(update : $Sub<T>) { ... }
setState<{ a: number; b: string }>({ a : 20 });
d180cf commented on Jul 28, 2015 It seems, that the appropriate place for such "generic meta types" (that would better be called "type expressions" or "computed types") is the .d.ts files. Currently they can contain only static type definitions, but could also contain "dynamic definitions":
/// [mytypes.d.ts]
declare module mytypes {
export type BasicType = (a, b) => number;
export type Intersection(a: ObjectLiteral, b: ObjectLiteral) {
const r = new ObjectLiteral;
for (const name of a.members) {
if (name in b.members) {
if (!Type.same(a.members[name], b.members[name]))
throw CompileError(...);
r.members[name] = a.members[name];
}
}
return r;
};
}
/// [sample.ts]
type X = { a: number; b: string };
type Y = { b: string; c: symbol };
type Z = mytypes.Intersection(X, Y);Such computed types could be compiled in some special "compilation context" in which all these Type and ObjectLiteral are defined. Then we could go even further and allow "type operators":
/// [mytypes.d.ts]
declare module mytypes {
export type "&" (a: ObjectLiteral, b: ObjectLiteral) {
return Intersection(a, b);
}
}Of course, some of these computed types will be pretty common and will naturally become a part of the standard types library:
/// [lib.d.ts]
type "&" (a: ObjectLiteral, b: ObjectLiteral) { ... }This should make it possible to express all fancy constructs that can exist in JS. benliddicott commented on Sep 14, 2015 It seems that part of the motivating case could be met by extending typeof to arbitrary expressions, as per #4233.
type C = $Merge<{a: number}, {b: string}>; // C = { a: number, b: string }
Would then become
// $Merge woiuld provide 20 or so overloads with 1 to 20 parameters.
// Here's the two parameter overload.
function $Merge<T1>(a1: T1): (T1&T2);
function $Merge<T1, T2>(a1: T1, a2: T2): (T1&T2);
function $Merge<T1, T2, T3>(a1: T1, a2: T2, a3: T3): (T1&T2&T3);
function $Merge(...args){return null;}
type C = typeof $Merge({a: number}, {b: string});
Args is harder to see. mhegazy commented on Feb 22, 2016 this is already covered by #2710
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|