-
Notifications
You must be signed in to change notification settings - Fork 12.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Type parameters as constraints #5949
Conversation
Conflicts: tests/baselines/reference/functionConstraintSatisfaction2.errors.txt
context.inferences[i].isFixed = true; | ||
return getInferredType(context, i); | ||
function getInferenceMapper(context: InferenceContext): TypeMapper { | ||
if (!context.mapper) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Invert the condition to reduce nesting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what you mean. There's a shared return statement at the bottom of the function and no else clause that would be reversed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant to just repeat the return
statement, but it's not really a big deal.
@mhegazy Want to comment on this one before I merge it? |
👍 |
@ahejlsberg I tried this out and upon grabbing quick info on interface Mapper<T> {
map<U extends T, V extends U[]>(f: (item: T) => U): V;
}
var m: Mapper<string>;
var a = m.map((x: string) => x); I expected |
@DanielRosenwasser Good catch. The problem is that the constraints aren't getting properly instantiated. Will put up a fix shortly. |
Hey @ahejlsberg, @Aleksey-Bykov wrote a useful example on #6037 which demonstrates the use of type parameters being able to extend each other. Can we add the following as a test case? function fold<a, r>(values: a[], result: r, fold: (result: r, value: a) => r): r {
for (let value of values) {
result = fold(result, value);
}
return result;
}
function append<a, b extends a>(values: a[], value: b): a[] {
values.push(value);
return values;
}
fold(
[1, 2, 3],
[] as [string, string][],
(result, value) => append(
result,
["", ""]
)
); |
by the way // test.ts
export function append<a, b extends a>(result: a[], value: b): a[] {
result.push(value);
return result;
} compiles with
but fails with
saying
|
created a separate bug: #6040 |
I noticed the same thing on my bug where the type parameter was not being instantiated. Can you enable |
Latest commits fix the uninstantiated type issue as well as issue in #6040. |
Awesome 🌹. I've done aweful things in the past : https://github.com/TypeScriptBuilder/tsb/blob/24c5bbaa3e29587ab0830194c374cd7fa8bb2462/src/app/state/simpleRedux.ts#L90-L103 :) |
@ahejlsberg I think it wouldn't be unreasonable to just get declaration emit for all of these tests. |
Type parameters as constraints
@basarat, a poorman's implementation of this feature could have been done by passing foo <a, b extends a>(foo: a, bar:b): void; vs foo <a, b>(foo: a, bar: b, bIsA: (val: b) => a): void; |
Question: does this patch support the following? I've come across this pattern way too frequently, and I've needed it for way too many things. In languages that support it, it's a very frequent idiom. interface Type<T extends Type<T>> {} |
@isiahmeadows Yes, that pattern (the "curiously recurring template pattern") is now supported. But also note that the polymorphic 'this' type is a more succinct way to accomplish the same thing. |
I also came across an unusual use case where I needed two F-bounded type On Thu, Dec 17, 2015, 09:31 Anders Hejlsberg notifications@github.com
|
With this PR it becomes possible for a type parameter constraint to reference type parameters from the same type parameter list (this was previously an error). For example:
A fancy term for this capability is F-Bounded Polymorphism.
Fixes #2304.