[Feature Request] Non-Union Generic Type Params #32909
Comments
|
Can it not be done using a helper type? type Check<T,U> = T extends unknown ? ExtractN<U,T> : never;
type ExtractN<T,U> = [T] extends [U] ? U : never;
type NonU<T> = Check<T,T>;
type SomeAlias<T extends NonU<T>> = T;
type A = SomeAlias<never>;
type B = SomeAlias<string>;
type C = SomeAlias<string|number>;
type D = SomeAlias<1 | 2 | 3>; |
|
Uhhh... Wtf? I'm surprised that doesn't give a circular constraint error or something. type Check<T,U> = T extends unknown ? ExtractN<U,T> : never;
type ExtractN<T,U> = [T] extends [U] ? U : never;
type NonU<T> = Check<T,T>;
type NonUnionX<T extends NonU<T> & (string|number)> = (
/*Implementation*/
T extends string ?
"str" :
T extends number ?
"num" :
never
);
//OK
type nonUnionX1 = NonUnionX<string>;
//Error, Type `NonUnionX` expects non-union for type parameter `0`
// `string|number` is a union type
type nonUnionX2 = NonUnionX<string|number>;
// ~~~~~~~~~~~~~
type UnionX<T extends string|number> = (
T extends string|number ?
NonUnionX<T> :
never
);
//OK
type unionX1 = UnionX<string>;
//OK
type unionX2 = UnionX<string|number>;
type Blah<T extends string|number> = (
//Error, Type `NonUnionX` expects non-union for type parameter `0`
// `T` may be a union type
NonUnionX<T>
// ~
);
type testInvalidParam = NonUnionX<boolean>
// ~~~~~~~Too bad I can't customize the error message, though. Being told a type isn't assignable to I'll play with this some more when I have the time and see if it messes with type inference for anything. If it doesn't mess with type inference, then you've basically solved my problem. Even this seems to work, type Passthrough<T extends NonU<T> & (string|number)> = (
NonUnionX<T>
);This is so awesome T^T |
|
Hmm.. I finally got the time to play with this, type Check<T,U> = T extends unknown ? ExtractN<U,T> : never;
type ExtractN<T,U> = [T] extends [U] ? U : never;
type NonU<T> = Check<T,T>;
function foo<T extends NonU<T> & { x : string }> (t : T) {
//Expected: OK!
//Actual : Property 'x' does not exist on type 'T'.
t.x
}
function foo2<T extends { x : string }> (t : T) {
//Expected: OK!
//Actual : OK!
t.x
}It seems like it complicates implementations quite a bit. This seems to be okay, function foo3<T extends NonU<T> & { x : string }> (t : T & { x : string }) {
//Expected: OK!
//Actual : OK!
t.x
}But duplicating the constraint is... Eh I guess I can still use this for helper types that do not have function implementations. So, still helpful! |
|
Seems like it doesn't work for object types, either, type Check<T,U> = T extends unknown ? ExtractN<U,T> : never;
type ExtractN<T,U> = [T] extends [U] ? U : never;
type NonU<T> = Check<T,T>;
type Obj = {
[k:string]:string
};
type NonUnionX<T extends NonU<T> & Obj> = (
/*Implementation*/
keyof Obj
);
type Blah<T extends Obj> = (
//Expected: Error
//Actual : OK
//We have not distributed `T` here, it should be treated as potentially
//being a union type
NonUnionX<T>
); |
|
I've been playing with this but I can't get it to work =/ export type UnionToIntersection<U> = (
(
U extends any ? (k: U) => void : never
) extends (
(k: infer I) => void
) ? I : never
);
type NonU<T> = [T] extends [UnionToIntersection<T>] ?
//Defer check to avoid circular constraint error, I think.
//Can't seem to just use "regular" T
//T :
(T extends any ? T : never) :
never;
type Constraint = {x:string};
type NonUnionX<T extends NonU<T> & Constraint> = (
/*Implementation*/
T["x"] extends "hi" ?
"hello" :
T["x"] extends "bye" ?
"goodbye" :
"???"
);
//OK
type nonUnionX1 = NonUnionX<{x:"hi"}>;
//Error, Type `NonUnionX` expects non-union for type parameter `0`
// `string|number` is a union type
type nonUnionX2 = NonUnionX<{x:"hi"}|{x:"bye"}>;
// ~~~~~~~~~~~~~
type UnionX<T extends Constraint> = (
T extends Constraint ?
//OK
NonUnionX<T> : //<-- Expected OK, Actual Error
never
);
//OK
type unionX1 = UnionX<{x:"hi"}>;
//OK
type unionX2 = UnionX<{x:"hi"}|{x:"bye"}>;
type Blah<T extends Constraint> = (
//Error, Type `NonUnionX` expects non-union for type parameter `0`
// `T` may be a union type
NonUnionX<T>
// ~
);
type testInvalidParam = NonUnionX<boolean>
// ~~~~~~~
type Passthrough<T extends NonU<T> & Constraint> = (
//OK
NonUnionX<T>
);@jack-williams Teach me, master Particularly, this part isn't working, type UnionX<T extends Constraint> = (
T extends Constraint ?
//OK
NonUnionX<T> : //<-- Expected OK, Actual Error
never
);After looking at your implementation, it looks like the type constraint must be a union type and requires at least two distinct elements. If that condition is satisfied, your utility type works. When the constraint type is not a union type, or either |
RyanCavanaugh
added
Awaiting More Feedback
|
The type I provided is almost certainly going to be brittle. In the example: type UnionX<T extends Constraint> = (
T extends Constraint ?
//OK
NonUnionX<T> : //<-- Expected OK, Actual Error
never
);I guess the assumption is that IMO, I don't think asking a type whether it is a union is a meaningful question. It would be like asking a number whether it is an addition or multiplication. Semantically, 1 + 3, 2 * 2, and 4, are all the same number that are independent of the notation used to specify them. Is the type |
|
I've already given an example of why it's semantically useful. In particular, many of my use cases happen to be that I need to guarantee type safety for a SQL query builder. And I need to either properly handle union cases or forbid them (if I cannot safely handle union types; either it is impossible or I'm not clever enough to guarantee it yet).
One of the simpler examples of it being helpful is asking what the primary key of a table is. If it is a non union type, then the pk of the table is whatever was defined as the pk (there can only be one per table). If it is a union type, then we have to ask if it is being used as an input or output. If it is an input to a function, then the pk is the intersection of all the PKs of each table of the union type. If it is an output of a function, then it is the union of all PKs of each table of the union type. Semantically important. I can dig up more examples of it being useful from my code base, if that example isn't convincing enough. A lot of things about TS are based on syntax. Sure, they're all brittle but it doesn't make those features any less useful |
|
Asking what the candidate key or super key of a union table type is actually more complex, if used as an input to a function. Because a table may have more than one candidate key. If it is not a union type, the CKs are the CKs of the table. If it is a union type and an output of a function, then it is the union of CKs of each table. If it is a union type and an input to a function, then the CKs are the... Cross product of each CK from each table. |
|
When trying to build this expression, What are valid types for If If |
|
In the above cases, it's pretty easy to guarantee type safety, even if union types are passed to a function. The exact way to guarantee safety is different for each problem (especially when you have correlated type params). But here's a situation where I can't quite guarantee safety by allowing union types because of how I want the function to be used. eqCandidateKeyOfTable(
myTable,
tableWithCandidateKeys,
columns => [columns.columnA, columns.columnB]
)If possible, I want to forbid a union type for The other two params may be union types and are fine. This is safe, eqCandidateKeyOfTable(
Math.random() > 0.5 ? myTable0 : myTable1,
tableWithCandidateKeys,
columns => [columns.columnA, columns.columnB]
)Because both This is not safe, eqCandidateKeyOfTable(
Math.random() > 0.5 ? myTable0 : myTable1,
tableWithCandidateKeys,
() => [myTable0.columns.columnA, myTable1.columns.columnB]
)Because the columns are from different tables now. I could muck around with the type of But it's extra work that is also brittle |
|
In all these cases, the constraint types are not union types. However, the concrete types may be unions. That sidesteps the issue of the constraint Even then, I don't agree the constraint you gave is meaningless. Without the Without the If we change the constraint to |
|
This is how I'm emulating the non-union constraint at function call sites. https://github.com/AnyhowStep/tsql/blob/master/src/select-clause/select-delegate.ts#L31 https://github.com/AnyhowStep/tsql/blob/master/src/type-util/is-union.ts#L6 I would still like it at the type level Just thought I'd elaborate further. This proposal is different from declare function foo<T extends oneof string|number> (t : T) : void;
declare function bar<T extends nonunion string|number> (t : T) : void;
//OK
//"x"|"y" extends string
//string is one of string|number
foo("x" as "x"|"y");
//Error
//"x"|"y" is a union type
bar("x" as "x"|"y");So, the non-union constraint is basically a stronger version of the one-of constraint |
|
|
I'm going to copy-paste my response from Gitter, I've said this many times before but overloads are terrible foo(arg:{x:string}):void;
foo(arg:{y:string}):void;
foo({x:"",y:""}); //OK, but expected errorThe overload thing only really works for simple cases. foo(arg:oneof {x:string}|{y:string}):voidYou can emulate this at function/method call sites at the moment with those fancy Like, >70% of my code is just TS type-level stuff and 30% or less is actual executable code. Emulating stuff at call-sites is only useful for downstream users but not for implementors A lot of my code has complex conditional types at call-sites for extra type safety (for downstream users) but none of that stuff really helps me as an implementor when I'm composing dozens of type aliases that I know will only work when the input type argument is a non-union type |
Search Terms
Suggestion
A way to annotate that a generic type param will not accept union types.
I don't have the syntax or keyword in mind, but I'll just go ahead and use
nonUnionas a kind of type param modifier,Use Cases
What do you want to use this for?
I work with pretty complex types (in my opinion); and a lot of them.
When working on a complex type, I tend to break the problem down into smaller subproblems.
The base case is usually assuming that all type params are non-union.
After that, I build on top of the base case and implement types that support union type params.
Here is an example type that is a base case,
PrimaryKey_NonUnion<TableT>And here is an example of a type building upon the base case,
PrimaryKey_Output<TableT>It distributes
TableTand usesPrimaryKey_NonUnion. The result is a union ifTableTis a union.And here is an example of another type building upon the base case,
PrimaryKey_Input<TableT>It distributes
TableTand usesPrimaryKey_NonUnion.Then, it uses
UnionToIntersection<>to combine the results into one type.That experimental repository of mine is filled with instances of generic types that support union types and those that do not.
There are times where you really do not want to pass a union type to a generic type param because it'll result in bugs that may not be noticed till later.
What shortcomings exist with current approaches?
One approach is to just write a comment that says,
This gets very error-prone when you start having hundreds of types.
Another approach is to give your types names that are descriptive,
This is still error-prone; you may still use it incorrectly.
Even if the name of the type says
NonUnionT, you may still pass a union type toT.Examples
A non-approach is to expose only types that handle union type params and to leave non-union implementations unexported.
This is not a useful approach because it means building new types in a different file using these non-union implementations becomes impossible. Since they're unexported.
Checklist
My suggestion meets these guidelines:
Similar issues
#24085
#27808
The text was updated successfully, but these errors were encountered: