Implement partial type argument inference using the _ sigil #26349
Conversation
|
Why write By default, it would infer. |
|
@alfaproject I wrote my rationale down in #26242 |
|
Would this PR enable this scenario? I didn't see a test quite like it. Basically extracting an inferred type parameter from a specified type parameter. type Box<T> = { value: T };
type HasBoxedNumber = Box<number>;
declare function foo<T extends Box<S>, S>(arg: T): S;
declare const hbn: HasBoxedNumber;
foo<HasBoxedNumber, infer>(hbn).toFixed(); |
|
Based on the design meeting feedback, this has been swapped to variant 2 from the proposal - using the |
As is, no. Other type parameters (supplied or no) are not currently inference sites for a type parameter. We could enable it here (just by performing some extra |
I don't think we want constraints to be inference sites, at least not without some explicit indication. At some point we might consider allowing type Unbox<T extends Box<infer U>> = U;Though you can get pretty much the same effect with conditional types: type Unbox<T extends Box<any>> = T extends Box<infer U> ? U : never; |
|
Alright, I'll leave this as is then and just mention that it's available as a branch if we ever change our minds in the future. |
weswigham
changed the title
|
@weswigham It seems inconsistent (and kinda strange) to use the type Tagged<O extends object, T> = O & { __tag: T };
// "Infer a type, and make it available under the alias 'T'"
declare function getTag<O extends Tagged<any, any>>(object: O): O extends Tagged<any, infer T> ? T : never;
// "Infer a type, and make it available to 'getTag' under the alias at the first type position"
getTag<infer>({ foo: string, __tag: 'bar' })
// => 'bar'This seems like an obvious syntactic duality to me... What was the reason you instead decided to go with |
|
The existing |
|
It would probably be nice to be able to declare infer on the functions, ex: |
Thanks for the response. :) Fair enough, but I'd argue that this decrease in consistency is far less than that of introducing an entirely new sigil for this purpose. Is there really a benefit to users in using such a radically different syntax for something whose only difference to |
|
Something else to consider is that TypeScript supports JSDoc, and If we're concerned about making operators/keywords context-sensitive, then again it seems like making |
|
I don't mind I'd also like to see this: const instance = new Blah<T, **>(1, 'b', false, new Date())I have a class that bundles many string literal types and I have to enumerate them all at every callsite even when I'm using the code from this branch. Everytime I add a new string literal I have to update every single callsite which is a massive drag ;) |
|
Consider: type LiteralMap<S1 extends string, S2 extends string, S3 extends string> = {
item1: S1,
item2: S2,
item3: S3
}With this feature at every definition using this type I have to use: function user(map: LiteralMap<*, *, *>) {}Now if I need to add a new literal to my map I have to update this to: type LiteralMap<S1 extends string, S2 extends string, S3 extends string, S4 extends string> = {
item1: S1,
item2: S2,
item3: S3,
item4: S4,
}which is no big deal, but now I also have to update every single use of this to: function user(map: LiteralMap<*, *, *, *>) {}With |
|
Or it could follow the tuple system type LiteralMap<S1?, S2?, S3?> = {
item1: S1,
item2: S2,
item3: S3
}
function user(map: LiteralMap) {} // infer, infer, infer
function user(map: LiteralMap<boolean>) {} // boolean, infer, infer
function user(map: LiteralMap<_, boolean>) {} // infer, boolean, infer
type LiteralMap<S1, S2, S3?> = {
item1: S1,
item2: S2,
item3: S3
}
function user(map: LiteralMap) {} // not allowed, S1 and S2 missing
function user(map: LiteralMap<boolean>) {} // not allowed, S2 missing
function user(map: LiteralMap<_, boolean>) {} // infer, boolean, inferalternatively it could use the default assignation (which I guess makes more sense, since if you want it to infer the default type makes no sense?) type LiteralMap<S1 = _, S2 = _, S3 = _> = {
item1: S1,
item2: S2,
item3: S3
}
function user(map: LiteralMap) {} // infer, infer, infer
function user(map: LiteralMap<boolean>) {} // boolean, infer, infer
function user(map: LiteralMap<*, boolean>) {} // infer, boolean, infer
type LiteralMap<S1, S2, S3 = _> = {
item1: S1,
item2: S2,
item3: S3
}
function user(map: LiteralMap) {} // not allowed, S1 and S2 missing
function user(map: LiteralMap<boolean>) {} // not allowed, S2 missing
function user(map: LiteralMap<_, boolean>) {} // infer, boolean, infer |
|
Much better than #23696. Great stuff 👍 Thanks! |
|
@RyanCavanaugh What the problem with this PR? Is this too complicated? I wait this feature more than 2 years. I really need this one in a lot of places. Currently I need to use dirty hacks like function x<A>() { return <B>(prop: {a: A, b: B})=>void}
x<number>()({a:1, b:'b'}) |
|
@typescript-bot test this |
|
Heya @weswigham, I've started to run the perf test suite on this PR at 814f86c. You can monitor the build here. Update: The results are in! |
|
Heya @weswigham, I've started to run the parallelized Definitely Typed test suite on this PR at 814f86c. You can monitor the build here. Update: The results are in! |
|
Heya @weswigham, I've started to run the extended test suite on this PR at 814f86c. You can monitor the build here. |
|
Heya @weswigham, I've started to run the diff-based top-repos suite on this PR at 814f86c. You can monitor the build here. Update: The results are in! |
|
@weswigham Here are the results of running the top-repos suite comparing Everything looks good! |
|
@weswigham Here they are:
CompilerComparison Report - main..26349
System
Hosts
Scenarios
TSServerComparison Report - main..26349
System
Hosts
Scenarios
StartupComparison Report - main..26349
System
Hosts
Scenarios
Developer Information: |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hey @weswigham, the results of running the DT tests are ready. |
weswigham
requested review from
sandersn and
andrewbranch
and removed request for
DanielRosenwasser,
ahejlsberg,
RyanCavanaugh and
a user
|
I've throught quite a bit about partial type inference and I agree that, while this is a good step forward, I have a need for definition-site inference much more often (I suspect the divergence of opinions we've seen upthread is likely splitting across library users vs. library authors - the latter of whom are concerned that requiring the caller to opt into inference doesn't really help in making safe/ergonomic/hard-to-misuse APIs). So I'd also like to see at least some thought toward whether/how this syntax fits in with a hypothetical future definition-site syntax. FWIW, I put together a gist a while back exploring this (see here, feedback appreciated), and concluded that |
|
Can we split generic types by some symbol, like ";". declare function foo <
// available outside
O extends Record<string, any>;
// private
V extends string
> (value: V): O & Record<'value', V>
const test = foo<{ test: true }>('value')
// test: { test: true } & { value: 'value' } |
Considering that EcmaScript has introduced and TypeScript has adopted an ergonomic declare function foo <
O extends Record<string, any>,
#V extends string
> (value: #V): O & Record<'value', #V>
const test = foo<{ test: true }>('value')
// test: { test: true } & { value: 'value' } |
|
I'd prefer if TypeScript didn't add non-standard features that look like private class fields, as it may increase usage of private class fields, which don't support certain libraries that rely on Proxies (including Vue). Alternatively, we could support both |
Looks qualified to me. I suggested ";" like in "for i" loop syntax. Any way, there are no cases to mix private and public types. I'm not sure about declare function foo <
#V extends string,
O extends Record<string, #V>
> (value: #V): O & Record<'value', #V>
const test = foo<{ test: true }>('value')
// test: { test: true } & { value: 'value' } |
|
This discussion of private generic parameters is getting a bit off-topic to this issue (though as I asserted above, it's tangentially relevant insofar as the syntax should work well together). I am very interested in continuing the private types discussion, but I think it's more appropriate on #42388 so I've moved the discussion there. As far as this specific issue goes, I'm definitely in favor, don't particularly care about |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
any updates here? would love the ability to partially supply generics while the remainder continue to infer |
…d as the path spec it all works except that we also take the returned value type as a type parameter, and typescript won't infer the pathspec string type to the literal passed if you pass the return type. its both or neither. when microsoft/TypeScript#26349 is merged, this should work
|
Coming from this issue: #19205 . It would be nice if the inference wouldn't be turned off. |
In this PR, we allow the
_sigil to appear in type argument lists in expression positions as a placeholder for locations where you would like inference to occur:This allows users to override a variable in a list of defaulted ones without actually explicitly providing the rest or allow a type variable to be inferred from another provided one.
Implements #26242.
Supersedes #23696.
Fixes #20122.
Fixes #10571.
Technically, this prevents you from passing a type named
_as a type argument (we do not reserve_in general and don't think we need to). Our suggested workaround is simply to rename or alias the type you wish to pass. Eg,we did a quick check over at big ts query, and didn't find any public projects which passed a type named
_as a type argument in an expression/inference position, so it seems like a relatively safe care-out to make.Prior work for the
_sigil for partial inference includes flow and f#, so it should end up being pretty familiar.