GeezerVison

Mohamed Hegazy (@mhegazy) Want to comment on this one before I merge it?

👍

Anders Hejlsberg (@ahejlsberg) I tried this out and upon grabbing quick info on a, I'm seeing an uninstantiated type:

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 a to have the type string[], so something isn't working out here.

Daniel Rosenwasser (@DanielRosenwasser) Good catch. The problem is that the constraints aren't getting properly instantiated. Will put up a fix shortly.

Hey Anders Hejlsberg (@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

node ./built/local/tsc.js --module commonjs test.ts 

but fails with

node ./built/local/tsc.js --module commonjs --declaration test.ts 

saying

test.ts(1,37): error TS4016: Type parameter 'b' of exported function has or is using private name 'a'.

created a separate bug: #6040

I noticed the same thing on my bug where the type parameter was not being instantiated. Can you enable // @declaration: true for all these test cases?

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 :)

Anders Hejlsberg (@ahejlsberg) I think it wouldn't be unreasonable to just get declaration emit for all of these tests.

Basarat Ali Syed (@basarat), a poorman's implementation of this feature could have been done by passing
a function that maps B to A thus enforcing the constraint, consider:

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
parameters, which the this type doesn't cover. Given this supports that
as well, I'm happy.

On Thu, Dec 17, 2015, 09:31 Anders Hejlsberg [email protected]
wrote:

@isiahmeadows https://github.com/isiahmeadows Yes, that pattern (the
"curiously recurring template pattern") is now supported. But also note
that the polymorphic 'this' type
#4910 is a more succinct
way to accomplish the same thing.

—
Reply to this email directly or view it on GitHub
#5949 (comment)
.