Defer indexed access T[K] with non-generic K

[Anders Hejlsberg (ahejlsberg)]

With this PR we defer resolution of indexed access types T[K] where T is generic and K is non-generic.

functiongetValue<Textends{value: string|number}>(obj: T): T['value']{returnobj.value;}letx1=getValue({value: 'hello'});// stringletx2=getValue({value: 42});// number

In the example above, the indexed access type T['value'] is permitted because T is constrained to a type that has a property named value. The type T['value'] behaves like a subtype of string | number because that is the type of value in the constraint type, and when instantiation substitutes an actual type for T, the type of the value property in that actual type is substituted for T['value'].

Note that for backwards compatibility reasons, the expression obj.value is still eagerly resolved to type string | number. The expression must be explicitly coerced to T['value'] using a type annotation or a type assertion in order to get the deferred behavior.

This PR also implements better circularity detection and reporting for indexed access types. For example:

typeT1={x: T1['x'];// Error};

Note that circularities may sometimes result only for certain arguments to type parameters.

typeT2<Kextends'x'|'y'>={x: T2<K>[K];// Errory: number;}declareletobj: T2<'x'>;letx=obj.x;

If the type of obj above is changed to T2<'y'> the circularity error goes away.

Fixes#12651.
Fixes#12723.
Fixes#12744.

[Edan Schwartz (eschwartz)]

I just want to point out that once this is fixed, we should be able to implement a better EventEmitter definition, with typed events.

For example

// Encapulate an event's name and datainterfaceEventType<TNameextendsstring,TDataextendsany>{name: TName;data: TData;}classEventEmitter<TEventTypeextendsEventType<string,any>>{on<TTypeextendsTEventType>(name: TType["name"],listener:(event: TType["data"])=>void):this;/*...*/}

Usage:

typeEventTypeA=EventType<'a',{foo: string;}>;typeEventTypeB=EventType<'b',{bar: string;}>;constemitter=newEventEmitter<EventTypeA|EventTypeB>();// emitter.on requires that the event name and data match the provided EventTypeemitter.on<EventTypeA>('a',(evt)=>{evt.foo;});emitter.on(EventTypeB>('b',(evt)=>{evt.bar;});

[Edan Schwartz (eschwartz)]

Any idea when this might be released? Should we be expecting a 2.1.5 to come out soon with this fix?

(also, thanks for all the work on this. This is really cool stuff, and I'm having a ton of fun using it)

[Rotem Dan (rotemdan)]

I believe I've found an alternative, though less elegant, approach to my dispatcher example that doesn't rely on discriminated unions and might work with the new inference capability described here without any need for additional syntax:

typeDispatcherSchema={[name: string]: {argTypes: any[];returnType: any}};classDispatcher<SextendsDispatcherSchema>{dispatch<KextendskeyofS>(name: K,args: S[K]['argTypes']): S[K]['returnType']{// ...}}typeMySchema={"read": {argTypes: [string,number];returnType: string[];};"write": {argTypes: [string,string[],boolean];returnType: number;};}constdispatcher=newDispatcher<MySchema>();varresult=dispatcher.dispatch("read",["myfile.txt",35]);// okvarresult=dispatcher.dispatch("read","myfile.txt");// already errorsvarresult=dispatcher.dispatch("reed",["myfile.txt",35]);// already errorsvarresult=dispatcher.dispatch("write",["myfile.txt","oops",true]);// might error with this PR?

It seems promising but I have not tested this yet though (I'm waiting for the pull request to be merged and arrive to the nightly builds).

(If this does prove to work I'll probably start applying this pattern literally immediately in my code...)

[Edan Schwartz (eschwartz)]

Just downloaded typescript@2.2.0-dev.20161212, and my EventEmitter example is working great 👍

[Edan Schwartz (eschwartz)]

Any chance this can make it into 2.1.5?

[Anders Hejlsberg (ahejlsberg)]

With this PR we defer resolution of indexed access types T[K] where T is generic and K is non-generic.

functiongetValue<Textends{value: string|number}>(obj: T): T['value']{returnobj.value;}letx1=getValue({value: 'hello'});// stringletx2=getValue({value: 42});// number

In the example above, the indexed access type T['value'] is permitted because T is constrained to a type that has a property named value. The type T['value'] behaves like a subtype of string | number because that is the type of value in the constraint type, and when instantiation substitutes an actual type for T, the type of the value property in that actual type is substituted for T['value'].

Note that for backwards compatibility reasons, the expression obj.value is still eagerly resolved to type string | number. The expression must be explicitly coerced to T['value'] using a type annotation or a type assertion in order to get the deferred behavior.

This PR also implements better circularity detection and reporting for indexed access types. For example:

typeT1={x: T1['x'];// Error};

Note that circularities may sometimes result only for certain arguments to type parameters.

typeT2<Kextends'x'|'y'>={x: T2<K>[K];// Errory: number;}declareletobj: T2<'x'>;letx=obj.x;

If the type of obj above is changed to T2<'y'> the circularity error goes away.

Fixes#12651.
Fixes#12723.
Fixes#12744.

[Edan Schwartz (eschwartz)]

I just want to point out that once this is fixed, we should be able to implement a better EventEmitter definition, with typed events.

For example

// Encapulate an event's name and datainterfaceEventType<TNameextendsstring,TDataextendsany>{name: TName;data: TData;}classEventEmitter<TEventTypeextendsEventType<string,any>>{on<TTypeextendsTEventType>(name: TType["name"],listener:(event: TType["data"])=>void):this;/*...*/}

Usage:

typeEventTypeA=EventType<'a',{foo: string;}>;typeEventTypeB=EventType<'b',{bar: string;}>;constemitter=newEventEmitter<EventTypeA|EventTypeB>();// emitter.on requires that the event name and data match the provided EventTypeemitter.on<EventTypeA>('a',(evt)=>{evt.foo;});emitter.on(EventTypeB>('b',(evt)=>{evt.bar;});

[Edan Schwartz (eschwartz)]

Any idea when this might be released? Should we be expecting a 2.1.5 to come out soon with this fix?

(also, thanks for all the work on this. This is really cool stuff, and I'm having a ton of fun using it)

[Rotem Dan (rotemdan)]

I believe I've found an alternative, though less elegant, approach to my dispatcher example that doesn't rely on discriminated unions and might work with the new inference capability described here without any need for additional syntax:

typeDispatcherSchema={[name: string]: {argTypes: any[];returnType: any}};classDispatcher<SextendsDispatcherSchema>{dispatch<KextendskeyofS>(name: K,args: S[K]['argTypes']): S[K]['returnType']{// ...}}typeMySchema={"read": {argTypes: [string,number];returnType: string[];};"write": {argTypes: [string,string[],boolean];returnType: number;};}constdispatcher=newDispatcher<MySchema>();varresult=dispatcher.dispatch("read",["myfile.txt",35]);// okvarresult=dispatcher.dispatch("read","myfile.txt");// already errorsvarresult=dispatcher.dispatch("reed",["myfile.txt",35]);// already errorsvarresult=dispatcher.dispatch("write",["myfile.txt","oops",true]);// might error with this PR?

It seems promising but I have not tested this yet though (I'm waiting for the pull request to be merged and arrive to the nightly builds).

(If this does prove to work I'll probably start applying this pattern literally immediately in my code...)

[Edan Schwartz (eschwartz)]

Just downloaded typescript@2.2.0-dev.20161212, and my EventEmitter example is working great 👍

[Edan Schwartz (eschwartz)]

Any chance this can make it into 2.1.5?

[Anders Hejlsberg (ahejlsberg)]

With this PR we defer resolution of indexed access types T[K] where T is generic and K is non-generic.

functiongetValue<Textends{value: string|number}>(obj: T): T['value']{returnobj.value;}letx1=getValue({value: 'hello'});// stringletx2=getValue({value: 42});// number

In the example above, the indexed access type T['value'] is permitted because T is constrained to a type that has a property named value. The type T['value'] behaves like a subtype of string | number because that is the type of value in the constraint type, and when instantiation substitutes an actual type for T, the type of the value property in that actual type is substituted for T['value'].

Note that for backwards compatibility reasons, the expression obj.value is still eagerly resolved to type string | number. The expression must be explicitly coerced to T['value'] using a type annotation or a type assertion in order to get the deferred behavior.

This PR also implements better circularity detection and reporting for indexed access types. For example:

typeT1={x: T1['x'];// Error};

Note that circularities may sometimes result only for certain arguments to type parameters.

typeT2<Kextends'x'|'y'>={x: T2<K>[K];// Errory: number;}declareletobj: T2<'x'>;letx=obj.x;

If the type of obj above is changed to T2<'y'> the circularity error goes away.

Fixes#12651.
Fixes#12723.
Fixes#12744.

[Edan Schwartz (eschwartz)]

I just want to point out that once this is fixed, we should be able to implement a better EventEmitter definition, with typed events.

For example

// Encapulate an event's name and datainterfaceEventType<TNameextendsstring,TDataextendsany>{name: TName;data: TData;}classEventEmitter<TEventTypeextendsEventType<string,any>>{on<TTypeextendsTEventType>(name: TType["name"],listener:(event: TType["data"])=>void):this;/*...*/}

Usage:

typeEventTypeA=EventType<'a',{foo: string;}>;typeEventTypeB=EventType<'b',{bar: string;}>;constemitter=newEventEmitter<EventTypeA|EventTypeB>();// emitter.on requires that the event name and data match the provided EventTypeemitter.on<EventTypeA>('a',(evt)=>{evt.foo;});emitter.on(EventTypeB>('b',(evt)=>{evt.bar;});

[Edan Schwartz (eschwartz)]

Any idea when this might be released? Should we be expecting a 2.1.5 to come out soon with this fix?

(also, thanks for all the work on this. This is really cool stuff, and I'm having a ton of fun using it)

[Rotem Dan (rotemdan)]

I believe I've found an alternative, though less elegant, approach to my dispatcher example that doesn't rely on discriminated unions and might work with the new inference capability described here without any need for additional syntax:

typeDispatcherSchema={[name: string]: {argTypes: any[];returnType: any}};classDispatcher<SextendsDispatcherSchema>{dispatch<KextendskeyofS>(name: K,args: S[K]['argTypes']): S[K]['returnType']{// ...}}typeMySchema={"read": {argTypes: [string,number];returnType: string[];};"write": {argTypes: [string,string[],boolean];returnType: number;};}constdispatcher=newDispatcher<MySchema>();varresult=dispatcher.dispatch("read",["myfile.txt",35]);// okvarresult=dispatcher.dispatch("read","myfile.txt");// already errorsvarresult=dispatcher.dispatch("reed",["myfile.txt",35]);// already errorsvarresult=dispatcher.dispatch("write",["myfile.txt","oops",true]);// might error with this PR?

It seems promising but I have not tested this yet though (I'm waiting for the pull request to be merged and arrive to the nightly builds).

(If this does prove to work I'll probably start applying this pattern literally immediately in my code...)

[Edan Schwartz (eschwartz)]

Just downloaded typescript@2.2.0-dev.20161212, and my EventEmitter example is working great 👍

[Edan Schwartz (eschwartz)]

Any chance this can make it into 2.1.5?

[Anders Hejlsberg (ahejlsberg)]

With this PR we defer resolution of indexed access types T[K] where T is generic and K is non-generic.

functiongetValue<Textends{value: string|number}>(obj: T): T['value']{returnobj.value;}letx1=getValue({value: 'hello'});// stringletx2=getValue({value: 42});// number

In the example above, the indexed access type T['value'] is permitted because T is constrained to a type that has a property named value. The type T['value'] behaves like a subtype of string | number because that is the type of value in the constraint type, and when instantiation substitutes an actual type for T, the type of the value property in that actual type is substituted for T['value'].

Note that for backwards compatibility reasons, the expression obj.value is still eagerly resolved to type string | number. The expression must be explicitly coerced to T['value'] using a type annotation or a type assertion in order to get the deferred behavior.

This PR also implements better circularity detection and reporting for indexed access types. For example:

typeT1={x: T1['x'];// Error};

Note that circularities may sometimes result only for certain arguments to type parameters.

typeT2<Kextends'x'|'y'>={x: T2<K>[K];// Errory: number;}declareletobj: T2<'x'>;letx=obj.x;

If the type of obj above is changed to T2<'y'> the circularity error goes away.

Fixes#12651.
Fixes#12723.
Fixes#12744.

[Edan Schwartz (eschwartz)]

I just want to point out that once this is fixed, we should be able to implement a better EventEmitter definition, with typed events.

For example

// Encapulate an event's name and datainterfaceEventType<TNameextendsstring,TDataextendsany>{name: TName;data: TData;}classEventEmitter<TEventTypeextendsEventType<string,any>>{on<TTypeextendsTEventType>(name: TType["name"],listener:(event: TType["data"])=>void):this;/*...*/}

Usage:

typeEventTypeA=EventType<'a',{foo: string;}>;typeEventTypeB=EventType<'b',{bar: string;}>;constemitter=newEventEmitter<EventTypeA|EventTypeB>();// emitter.on requires that the event name and data match the provided EventTypeemitter.on<EventTypeA>('a',(evt)=>{evt.foo;});emitter.on(EventTypeB>('b',(evt)=>{evt.bar;});

[Edan Schwartz (eschwartz)]

Any idea when this might be released? Should we be expecting a 2.1.5 to come out soon with this fix?

(also, thanks for all the work on this. This is really cool stuff, and I'm having a ton of fun using it)

[Rotem Dan (rotemdan)]

I believe I've found an alternative, though less elegant, approach to my dispatcher example that doesn't rely on discriminated unions and might work with the new inference capability described here without any need for additional syntax:

typeDispatcherSchema={[name: string]: {argTypes: any[];returnType: any}};classDispatcher<SextendsDispatcherSchema>{dispatch<KextendskeyofS>(name: K,args: S[K]['argTypes']): S[K]['returnType']{// ...}}typeMySchema={"read": {argTypes: [string,number];returnType: string[];};"write": {argTypes: [string,string[],boolean];returnType: number;};}constdispatcher=newDispatcher<MySchema>();varresult=dispatcher.dispatch("read",["myfile.txt",35]);// okvarresult=dispatcher.dispatch("read","myfile.txt");// already errorsvarresult=dispatcher.dispatch("reed",["myfile.txt",35]);// already errorsvarresult=dispatcher.dispatch("write",["myfile.txt","oops",true]);// might error with this PR?

It seems promising but I have not tested this yet though (I'm waiting for the pull request to be merged and arrive to the nightly builds).

(If this does prove to work I'll probably start applying this pattern literally immediately in my code...)

[Edan Schwartz (eschwartz)]

Just downloaded typescript@2.2.0-dev.20161212, and my EventEmitter example is working great 👍

[Edan Schwartz (eschwartz)]

Any chance this can make it into 2.1.5?

[Anders Hejlsberg (ahejlsberg)]

With this PR we defer resolution of indexed access types T[K] where T is generic and K is non-generic.

functiongetValue<Textends{value: string|number}>(obj: T): T['value']{returnobj.value;}letx1=getValue({value: 'hello'});// stringletx2=getValue({value: 42});// number

In the example above, the indexed access type T['value'] is permitted because T is constrained to a type that has a property named value. The type T['value'] behaves like a subtype of string | number because that is the type of value in the constraint type, and when instantiation substitutes an actual type for T, the type of the value property in that actual type is substituted for T['value'].

Note that for backwards compatibility reasons, the expression obj.value is still eagerly resolved to type string | number. The expression must be explicitly coerced to T['value'] using a type annotation or a type assertion in order to get the deferred behavior.

This PR also implements better circularity detection and reporting for indexed access types. For example:

typeT1={x: T1['x'];// Error};

Note that circularities may sometimes result only for certain arguments to type parameters.

typeT2<Kextends'x'|'y'>={x: T2<K>[K];// Errory: number;}declareletobj: T2<'x'>;letx=obj.x;

If the type of obj above is changed to T2<'y'> the circularity error goes away.

Fixes#12651.
Fixes#12723.
Fixes#12744.

[Edan Schwartz (eschwartz)]

I just want to point out that once this is fixed, we should be able to implement a better EventEmitter definition, with typed events.

For example

// Encapulate an event's name and datainterfaceEventType<TNameextendsstring,TDataextendsany>{name: TName;data: TData;}classEventEmitter<TEventTypeextendsEventType<string,any>>{on<TTypeextendsTEventType>(name: TType["name"],listener:(event: TType["data"])=>void):this;/*...*/}

Usage:

typeEventTypeA=EventType<'a',{foo: string;}>;typeEventTypeB=EventType<'b',{bar: string;}>;constemitter=newEventEmitter<EventTypeA|EventTypeB>();// emitter.on requires that the event name and data match the provided EventTypeemitter.on<EventTypeA>('a',(evt)=>{evt.foo;});emitter.on(EventTypeB>('b',(evt)=>{evt.bar;});

[Edan Schwartz (eschwartz)]

Any idea when this might be released? Should we be expecting a 2.1.5 to come out soon with this fix?

(also, thanks for all the work on this. This is really cool stuff, and I'm having a ton of fun using it)

[Rotem Dan (rotemdan)]

I believe I've found an alternative, though less elegant, approach to my dispatcher example that doesn't rely on discriminated unions and might work with the new inference capability described here without any need for additional syntax:

typeDispatcherSchema={[name: string]: {argTypes: any[];returnType: any}};classDispatcher<SextendsDispatcherSchema>{dispatch<KextendskeyofS>(name: K,args: S[K]['argTypes']): S[K]['returnType']{// ...}}typeMySchema={"read": {argTypes: [string,number];returnType: string[];};"write": {argTypes: [string,string[],boolean];returnType: number;};}constdispatcher=newDispatcher<MySchema>();varresult=dispatcher.dispatch("read",["myfile.txt",35]);// okvarresult=dispatcher.dispatch("read","myfile.txt");// already errorsvarresult=dispatcher.dispatch("reed",["myfile.txt",35]);// already errorsvarresult=dispatcher.dispatch("write",["myfile.txt","oops",true]);// might error with this PR?

It seems promising but I have not tested this yet though (I'm waiting for the pull request to be merged and arrive to the nightly builds).

(If this does prove to work I'll probably start applying this pattern literally immediately in my code...)

[Edan Schwartz (eschwartz)]

Just downloaded typescript@2.2.0-dev.20161212, and my EventEmitter example is working great 👍

[Edan Schwartz (eschwartz)]

Any chance this can make it into 2.1.5?

[Anders Hejlsberg (ahejlsberg)]

With this PR we defer resolution of indexed access types T[K] where T is generic and K is non-generic.

functiongetValue<Textends{value: string|number}>(obj: T): T['value']{returnobj.value;}letx1=getValue({value: 'hello'});// stringletx2=getValue({value: 42});// number

In the example above, the indexed access type T['value'] is permitted because T is constrained to a type that has a property named value. The type T['value'] behaves like a subtype of string | number because that is the type of value in the constraint type, and when instantiation substitutes an actual type for T, the type of the value property in that actual type is substituted for T['value'].

Note that for backwards compatibility reasons, the expression obj.value is still eagerly resolved to type string | number. The expression must be explicitly coerced to T['value'] using a type annotation or a type assertion in order to get the deferred behavior.

This PR also implements better circularity detection and reporting for indexed access types. For example:

typeT1={x: T1['x'];// Error};

Note that circularities may sometimes result only for certain arguments to type parameters.

typeT2<Kextends'x'|'y'>={x: T2<K>[K];// Errory: number;}declareletobj: T2<'x'>;letx=obj.x;

If the type of obj above is changed to T2<'y'> the circularity error goes away.

Fixes#12651.
Fixes#12723.
Fixes#12744.

[Edan Schwartz (eschwartz)]

I just want to point out that once this is fixed, we should be able to implement a better EventEmitter definition, with typed events.

For example

// Encapulate an event's name and datainterfaceEventType<TNameextendsstring,TDataextendsany>{name: TName;data: TData;}classEventEmitter<TEventTypeextendsEventType<string,any>>{on<TTypeextendsTEventType>(name: TType["name"],listener:(event: TType["data"])=>void):this;/*...*/}

Usage:

typeEventTypeA=EventType<'a',{foo: string;}>;typeEventTypeB=EventType<'b',{bar: string;}>;constemitter=newEventEmitter<EventTypeA|EventTypeB>();// emitter.on requires that the event name and data match the provided EventTypeemitter.on<EventTypeA>('a',(evt)=>{evt.foo;});emitter.on(EventTypeB>('b',(evt)=>{evt.bar;});

[Edan Schwartz (eschwartz)]

Any idea when this might be released? Should we be expecting a 2.1.5 to come out soon with this fix?

(also, thanks for all the work on this. This is really cool stuff, and I'm having a ton of fun using it)

[Rotem Dan (rotemdan)]

I believe I've found an alternative, though less elegant, approach to my dispatcher example that doesn't rely on discriminated unions and might work with the new inference capability described here without any need for additional syntax:

typeDispatcherSchema={[name: string]: {argTypes: any[];returnType: any}};classDispatcher<SextendsDispatcherSchema>{dispatch<KextendskeyofS>(name: K,args: S[K]['argTypes']): S[K]['returnType']{// ...}}typeMySchema={"read": {argTypes: [string,number];returnType: string[];};"write": {argTypes: [string,string[],boolean];returnType: number;};}constdispatcher=newDispatcher<MySchema>();varresult=dispatcher.dispatch("read",["myfile.txt",35]);// okvarresult=dispatcher.dispatch("read","myfile.txt");// already errorsvarresult=dispatcher.dispatch("reed",["myfile.txt",35]);// already errorsvarresult=dispatcher.dispatch("write",["myfile.txt","oops",true]);// might error with this PR?

It seems promising but I have not tested this yet though (I'm waiting for the pull request to be merged and arrive to the nightly builds).

(If this does prove to work I'll probably start applying this pattern literally immediately in my code...)

[Edan Schwartz (eschwartz)]

Just downloaded typescript@2.2.0-dev.20161212, and my EventEmitter example is working great 👍

[Edan Schwartz (eschwartz)]

Any chance this can make it into 2.1.5?

[Anders Hejlsberg (ahejlsberg)]

With this PR we defer resolution of indexed access types T[K] where T is generic and K is non-generic.

functiongetValue<Textends{value: string|number}>(obj: T): T['value']{returnobj.value;}letx1=getValue({value: 'hello'});// stringletx2=getValue({value: 42});// number

In the example above, the indexed access type T['value'] is permitted because T is constrained to a type that has a property named value. The type T['value'] behaves like a subtype of string | number because that is the type of value in the constraint type, and when instantiation substitutes an actual type for T, the type of the value property in that actual type is substituted for T['value'].

Note that for backwards compatibility reasons, the expression obj.value is still eagerly resolved to type string | number. The expression must be explicitly coerced to T['value'] using a type annotation or a type assertion in order to get the deferred behavior.

This PR also implements better circularity detection and reporting for indexed access types. For example:

typeT1={x: T1['x'];// Error};

Note that circularities may sometimes result only for certain arguments to type parameters.

typeT2<Kextends'x'|'y'>={x: T2<K>[K];// Errory: number;}declareletobj: T2<'x'>;letx=obj.x;

If the type of obj above is changed to T2<'y'> the circularity error goes away.

Fixes#12651.
Fixes#12723.
Fixes#12744.

[Edan Schwartz (eschwartz)]

I just want to point out that once this is fixed, we should be able to implement a better EventEmitter definition, with typed events.

For example

// Encapulate an event's name and datainterfaceEventType<TNameextendsstring,TDataextendsany>{name: TName;data: TData;}classEventEmitter<TEventTypeextendsEventType<string,any>>{on<TTypeextendsTEventType>(name: TType["name"],listener:(event: TType["data"])=>void):this;/*...*/}

Usage:

typeEventTypeA=EventType<'a',{foo: string;}>;typeEventTypeB=EventType<'b',{bar: string;}>;constemitter=newEventEmitter<EventTypeA|EventTypeB>();// emitter.on requires that the event name and data match the provided EventTypeemitter.on<EventTypeA>('a',(evt)=>{evt.foo;});emitter.on(EventTypeB>('b',(evt)=>{evt.bar;});

[Edan Schwartz (eschwartz)]

Any idea when this might be released? Should we be expecting a 2.1.5 to come out soon with this fix?

(also, thanks for all the work on this. This is really cool stuff, and I'm having a ton of fun using it)

[Rotem Dan (rotemdan)]

I believe I've found an alternative, though less elegant, approach to my dispatcher example that doesn't rely on discriminated unions and might work with the new inference capability described here without any need for additional syntax:

typeDispatcherSchema={[name: string]: {argTypes: any[];returnType: any}};classDispatcher<SextendsDispatcherSchema>{dispatch<KextendskeyofS>(name: K,args: S[K]['argTypes']): S[K]['returnType']{// ...}}typeMySchema={"read": {argTypes: [string,number];returnType: string[];};"write": {argTypes: [string,string[],boolean];returnType: number;};}constdispatcher=newDispatcher<MySchema>();varresult=dispatcher.dispatch("read",["myfile.txt",35]);// okvarresult=dispatcher.dispatch("read","myfile.txt");// already errorsvarresult=dispatcher.dispatch("reed",["myfile.txt",35]);// already errorsvarresult=dispatcher.dispatch("write",["myfile.txt","oops",true]);// might error with this PR?

It seems promising but I have not tested this yet though (I'm waiting for the pull request to be merged and arrive to the nightly builds).

(If this does prove to work I'll probably start applying this pattern literally immediately in my code...)

[Edan Schwartz (eschwartz)]

Just downloaded typescript@2.2.0-dev.20161212, and my EventEmitter example is working great 👍

[Edan Schwartz (eschwartz)]

Any chance this can make it into 2.1.5?

[Anders Hejlsberg (ahejlsberg)]

With this PR we defer resolution of indexed access types T[K] where T is generic and K is non-generic.

functiongetValue<Textends{value: string|number}>(obj: T): T['value']{returnobj.value;}letx1=getValue({value: 'hello'});// stringletx2=getValue({value: 42});// number

In the example above, the indexed access type T['value'] is permitted because T is constrained to a type that has a property named value. The type T['value'] behaves like a subtype of string | number because that is the type of value in the constraint type, and when instantiation substitutes an actual type for T, the type of the value property in that actual type is substituted for T['value'].

Note that for backwards compatibility reasons, the expression obj.value is still eagerly resolved to type string | number. The expression must be explicitly coerced to T['value'] using a type annotation or a type assertion in order to get the deferred behavior.

This PR also implements better circularity detection and reporting for indexed access types. For example:

typeT1={x: T1['x'];// Error};

Note that circularities may sometimes result only for certain arguments to type parameters.

typeT2<Kextends'x'|'y'>={x: T2<K>[K];// Errory: number;}declareletobj: T2<'x'>;letx=obj.x;

If the type of obj above is changed to T2<'y'> the circularity error goes away.

Fixes#12651.
Fixes#12723.
Fixes#12744.

[Edan Schwartz (eschwartz)]

I just want to point out that once this is fixed, we should be able to implement a better EventEmitter definition, with typed events.

For example

// Encapulate an event's name and datainterfaceEventType<TNameextendsstring,TDataextendsany>{name: TName;data: TData;}classEventEmitter<TEventTypeextendsEventType<string,any>>{on<TTypeextendsTEventType>(name: TType["name"],listener:(event: TType["data"])=>void):this;/*...*/}

Usage:

typeEventTypeA=EventType<'a',{foo: string;}>;typeEventTypeB=EventType<'b',{bar: string;}>;constemitter=newEventEmitter<EventTypeA|EventTypeB>();// emitter.on requires that the event name and data match the provided EventTypeemitter.on<EventTypeA>('a',(evt)=>{evt.foo;});emitter.on(EventTypeB>('b',(evt)=>{evt.bar;});

[Edan Schwartz (eschwartz)]

Any idea when this might be released? Should we be expecting a 2.1.5 to come out soon with this fix?

(also, thanks for all the work on this. This is really cool stuff, and I'm having a ton of fun using it)

[Rotem Dan (rotemdan)]

I believe I've found an alternative, though less elegant, approach to my dispatcher example that doesn't rely on discriminated unions and might work with the new inference capability described here without any need for additional syntax:

typeDispatcherSchema={[name: string]: {argTypes: any[];returnType: any}};classDispatcher<SextendsDispatcherSchema>{dispatch<KextendskeyofS>(name: K,args: S[K]['argTypes']): S[K]['returnType']{// ...}}typeMySchema={"read": {argTypes: [string,number];returnType: string[];};"write": {argTypes: [string,string[],boolean];returnType: number;};}constdispatcher=newDispatcher<MySchema>();varresult=dispatcher.dispatch("read",["myfile.txt",35]);// okvarresult=dispatcher.dispatch("read","myfile.txt");// already errorsvarresult=dispatcher.dispatch("reed",["myfile.txt",35]);// already errorsvarresult=dispatcher.dispatch("write",["myfile.txt","oops",true]);// might error with this PR?

It seems promising but I have not tested this yet though (I'm waiting for the pull request to be merged and arrive to the nightly builds).

(If this does prove to work I'll probably start applying this pattern literally immediately in my code...)

[Edan Schwartz (eschwartz)]

Just downloaded typescript@2.2.0-dev.20161212, and my EventEmitter example is working great 👍

[Edan Schwartz (eschwartz)]

Any chance this can make it into 2.1.5?