Repository navigation
Suggestion: Upper-bound generic type constraints #9252
Description
Activity
Artur Eshenbrener (@Strate), Those really aren't duplicates at all. They're very different, both conceptually and practically.
That said, I'm quite surprised this hasn't been proposed previously, so I suspected it was a duplicate, although I couldn't find anything.
Greg Ros (@GregRos) that tickets (especially #4889) contains discussion very close to your suggestion. For example, see this comment, or that. I wouldn't say that is it very different.
Open Source Projects from State (@State) yup, those comments are exactly my proposal, though the proposals themselves are different. I'm not sure if that means this is a duplicate or not.
Incidentally, I had no idea Java supported this kind of constraint. I thought it was just a Scala thing.
On second thought, #4889 can be used to get the same effect in some cases. One example where it can't is the following:
blah<Partial extended by Full>(partial : Partial) : Partial { return partial; } //type information is preserved.And one example where that proposal can do something that mine can't:
blah() : partial Full { //Full : {a : number, b : number} return {}; //or: return {a : 4}; //etc }e.g. The function can return different supertypes of
Full. This partial type is basically the same as a supertype constraint combined with existential types. It lets you say "X is some supertype of Foo, but no one knows which one".#371 is similar to #4889. So you're right, on second thought, they're not very different.
Reacted by Artur Eshenbrener- locked and limited conversation to collaborators
on Jun 19, 2018 - unlocked this conversation
on Oct 9, 2018 Greg Ros (@GregRos) this is an interesting idea and I also think the language would benefit from such a keyword.
As a workaround you can set an upper boundary in the param using a helper type:
type Full = { a: string b?: string } /** * Subset * @desc From `T` pick properties that exist in `U` */ type Subset<T, U> = { [key in keyof T]: key extends keyof U ? T[key] : never } function acceptFullAndMore<T extends Full>(param: T): T { return param } acceptFullAndMore({a: '', c: 1}) // Compiler allows `c`, even if it's not part of `Full` function acceptFull<T extends Full>(param: Subset<T, Full>): T { return param } acceptFull({a: '', c: 1}) // Compiler throws here 🙏
Reacted by Johannes Schickling and AdrianHow could the previous example from Greg Ros (@GregRos) be achieved with the Partial<> type?
blah<Partial extended by Full>(partial : Partial) : Partial { return partial; } //type information is preserved.(where Partial is not actually the new Partial type from Typescript but his own type)
Greg Ros (@GregRos) this is an interesting idea and I also think the language would benefit from such a keyword.
As a workaround you can set an upper boundary in the param using a helper type:
type Full = { a: string b?: string } /** * Subset * @desc From `T` pick properties that exist in `U` */ type Subset<T, U> = { [key in keyof T]: key extends keyof U ? T[key] : never } function acceptFullAndMore<T extends Full>(param: T): T { return param } acceptFullAndMore({a: '', c: 1}) // Compiler allows `c`, even if it's not part of `Full` function acceptFull<T extends Full>(param: Subset<T, Full>): T { return param } acceptFull({a: '', c: 1}) // Compiler throws here 🙏
Such a workaround requires a specific upper bound. However, in most cases, the upper bound is quite universal, like
string,object, or simplyany. We only want to filter out certain types without an exact supertype.
These scenarios seem to fit in the semantics ofExclude<T, U>. However, this utility type also requires the supertypeTto be specific, namely, union types. Universal types likestringdon't work as well, for instance,Exclude<string, "foo">results instring.
This proposal is logically connected with #4196. With a negating type, assumingNot<T>, the upper-bound could be transformed into a lower-bound with the help ofnever:type UpperToLower<T extends object> = Partial<T> & Record<string & Not<keyof T>, never>;
So maybe this could be regarded as a sub-scenario to #4196.
Reacted by 0x269Cross referencing #14520.
This is a proposal for generic structural supertype constraints.
I'll first detail the proposal, and then get into a discussion about use-cases.
Proposal
A supertype constraint is a constraint on a generic type parameter to be the structural supertype of another type. It's like a subtype/inheritance constraint, but from the other direction. For example, let's say we have a square:
In this suggested syntax, you could write:
This means the type
Tmust be a structural supertype of square. So the potential candidates forTare:It's an established kind of type constraint, not something I just made up. Although it's not exactly common, some languages do implement this feature, such as Scala. In Scala, you can write:
To express a supertype/upper bound constraint. In this case, of course, the constraint isn't structural --
Tmust declare that it implementsSquare.Utility
In most languages, including Scala, this kind of constraint isn't very useful. It only comes up in certain specific situations.
However, Javascript libraries often have this kind of API, where you're allowed to specify the partial properties of an object to modify it (the rest remain at their previous value).
In many cases, you can support this by having optional interface members, but isn't always possible or correct.
An important example is React, which defines a method called
setState:The right signature for this method should be:
Currently,the definition files state that it is:
Which doesn't fully capture the functionality of the method.
Notes
The suggested syntax doesn't give us a nice way of combining both subtype and supertype constraints. One possibility is: