TypeScript never type inconsistently matched in conditional type?












1















In the following code you notice that the type of Result1 is never, yet the type of test3 is . I can't make sense of this. Why are the results not the same, considering that they are both reading the never type from MyEvents?



type EventArgs<EventTypes, K extends keyof EventTypes> =
EventTypes[K] extends never /* CHECK NEVER */
?
: EventTypes[K] extends any
? EventTypes[K]
: [EventTypes[K]];

type foo<T> = T extends never /* CHECK NEVER */ ? : [boolean]
type Result1 = foo<MyEvents['anotherEvent']> // HERE, type is `never`

type MyEvents = {
anotherEvent: never // event has no args
}

type Result2 = EventArgs<MyEvents, 'anotherEvent'> // HERE, type is ``


playground link










share|improve this question

























  • What is your original goal, aka original problem? Without it it's hard to understand what you're trying to achieve.

    – Nurbol Alpysbayev
    Dec 31 '18 at 7:23











  • @NurbolAlpysbayev Hi, I had a typo, I fixed the question so that foo is checking never in the conditional. Notice that the result type in Result1 is never, yet the result in Result2 is . Just curious why this is? Because it seems like they both land on in the conditional check.

    – trusktr
    Dec 31 '18 at 7:26











  • It seems to me that you are using never type completely wrong. Do you want by never to indicate that there are no items? If yes it should be done by or null. never is not for that. And I hardly can imagine that something can extend never.

    – Nurbol Alpysbayev
    Dec 31 '18 at 7:26













  • Just write your original goal and we'll sort it out easily, I think.

    – Nurbol Alpysbayev
    Dec 31 '18 at 7:29













  • @NurbolAlpysbayev It's because I am doing this (stackoverflow.com/questions/53568797) and instead of using undefined I thought I would try never to see what happens, and found that the result is inconsistent, so I'm just trying to understand why. In practice, I think undefined is fine for defining what the args of the event in that other question should be, because if I actually wanted to define an arg of type undefined that wouldn't make much sense in the runtime JS code anyways.

    – trusktr
    Dec 31 '18 at 7:33
















1















In the following code you notice that the type of Result1 is never, yet the type of test3 is . I can't make sense of this. Why are the results not the same, considering that they are both reading the never type from MyEvents?



type EventArgs<EventTypes, K extends keyof EventTypes> =
EventTypes[K] extends never /* CHECK NEVER */
?
: EventTypes[K] extends any
? EventTypes[K]
: [EventTypes[K]];

type foo<T> = T extends never /* CHECK NEVER */ ? : [boolean]
type Result1 = foo<MyEvents['anotherEvent']> // HERE, type is `never`

type MyEvents = {
anotherEvent: never // event has no args
}

type Result2 = EventArgs<MyEvents, 'anotherEvent'> // HERE, type is ``


playground link










share|improve this question

























  • What is your original goal, aka original problem? Without it it's hard to understand what you're trying to achieve.

    – Nurbol Alpysbayev
    Dec 31 '18 at 7:23











  • @NurbolAlpysbayev Hi, I had a typo, I fixed the question so that foo is checking never in the conditional. Notice that the result type in Result1 is never, yet the result in Result2 is . Just curious why this is? Because it seems like they both land on in the conditional check.

    – trusktr
    Dec 31 '18 at 7:26











  • It seems to me that you are using never type completely wrong. Do you want by never to indicate that there are no items? If yes it should be done by or null. never is not for that. And I hardly can imagine that something can extend never.

    – Nurbol Alpysbayev
    Dec 31 '18 at 7:26













  • Just write your original goal and we'll sort it out easily, I think.

    – Nurbol Alpysbayev
    Dec 31 '18 at 7:29













  • @NurbolAlpysbayev It's because I am doing this (stackoverflow.com/questions/53568797) and instead of using undefined I thought I would try never to see what happens, and found that the result is inconsistent, so I'm just trying to understand why. In practice, I think undefined is fine for defining what the args of the event in that other question should be, because if I actually wanted to define an arg of type undefined that wouldn't make much sense in the runtime JS code anyways.

    – trusktr
    Dec 31 '18 at 7:33














1












1








1








In the following code you notice that the type of Result1 is never, yet the type of test3 is . I can't make sense of this. Why are the results not the same, considering that they are both reading the never type from MyEvents?



type EventArgs<EventTypes, K extends keyof EventTypes> =
EventTypes[K] extends never /* CHECK NEVER */
?
: EventTypes[K] extends any
? EventTypes[K]
: [EventTypes[K]];

type foo<T> = T extends never /* CHECK NEVER */ ? : [boolean]
type Result1 = foo<MyEvents['anotherEvent']> // HERE, type is `never`

type MyEvents = {
anotherEvent: never // event has no args
}

type Result2 = EventArgs<MyEvents, 'anotherEvent'> // HERE, type is ``


playground link










share|improve this question
















In the following code you notice that the type of Result1 is never, yet the type of test3 is . I can't make sense of this. Why are the results not the same, considering that they are both reading the never type from MyEvents?



type EventArgs<EventTypes, K extends keyof EventTypes> =
EventTypes[K] extends never /* CHECK NEVER */
?
: EventTypes[K] extends any
? EventTypes[K]
: [EventTypes[K]];

type foo<T> = T extends never /* CHECK NEVER */ ? : [boolean]
type Result1 = foo<MyEvents['anotherEvent']> // HERE, type is `never`

type MyEvents = {
anotherEvent: never // event has no args
}

type Result2 = EventArgs<MyEvents, 'anotherEvent'> // HERE, type is ``


playground link







typescript






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 31 '18 at 7:28







trusktr

















asked Dec 31 '18 at 7:13









trusktrtrusktr

17k30116162




17k30116162













  • What is your original goal, aka original problem? Without it it's hard to understand what you're trying to achieve.

    – Nurbol Alpysbayev
    Dec 31 '18 at 7:23











  • @NurbolAlpysbayev Hi, I had a typo, I fixed the question so that foo is checking never in the conditional. Notice that the result type in Result1 is never, yet the result in Result2 is . Just curious why this is? Because it seems like they both land on in the conditional check.

    – trusktr
    Dec 31 '18 at 7:26











  • It seems to me that you are using never type completely wrong. Do you want by never to indicate that there are no items? If yes it should be done by or null. never is not for that. And I hardly can imagine that something can extend never.

    – Nurbol Alpysbayev
    Dec 31 '18 at 7:26













  • Just write your original goal and we'll sort it out easily, I think.

    – Nurbol Alpysbayev
    Dec 31 '18 at 7:29













  • @NurbolAlpysbayev It's because I am doing this (stackoverflow.com/questions/53568797) and instead of using undefined I thought I would try never to see what happens, and found that the result is inconsistent, so I'm just trying to understand why. In practice, I think undefined is fine for defining what the args of the event in that other question should be, because if I actually wanted to define an arg of type undefined that wouldn't make much sense in the runtime JS code anyways.

    – trusktr
    Dec 31 '18 at 7:33



















  • What is your original goal, aka original problem? Without it it's hard to understand what you're trying to achieve.

    – Nurbol Alpysbayev
    Dec 31 '18 at 7:23











  • @NurbolAlpysbayev Hi, I had a typo, I fixed the question so that foo is checking never in the conditional. Notice that the result type in Result1 is never, yet the result in Result2 is . Just curious why this is? Because it seems like they both land on in the conditional check.

    – trusktr
    Dec 31 '18 at 7:26











  • It seems to me that you are using never type completely wrong. Do you want by never to indicate that there are no items? If yes it should be done by or null. never is not for that. And I hardly can imagine that something can extend never.

    – Nurbol Alpysbayev
    Dec 31 '18 at 7:26













  • Just write your original goal and we'll sort it out easily, I think.

    – Nurbol Alpysbayev
    Dec 31 '18 at 7:29













  • @NurbolAlpysbayev It's because I am doing this (stackoverflow.com/questions/53568797) and instead of using undefined I thought I would try never to see what happens, and found that the result is inconsistent, so I'm just trying to understand why. In practice, I think undefined is fine for defining what the args of the event in that other question should be, because if I actually wanted to define an arg of type undefined that wouldn't make much sense in the runtime JS code anyways.

    – trusktr
    Dec 31 '18 at 7:33

















What is your original goal, aka original problem? Without it it's hard to understand what you're trying to achieve.

– Nurbol Alpysbayev
Dec 31 '18 at 7:23





What is your original goal, aka original problem? Without it it's hard to understand what you're trying to achieve.

– Nurbol Alpysbayev
Dec 31 '18 at 7:23













@NurbolAlpysbayev Hi, I had a typo, I fixed the question so that foo is checking never in the conditional. Notice that the result type in Result1 is never, yet the result in Result2 is . Just curious why this is? Because it seems like they both land on in the conditional check.

– trusktr
Dec 31 '18 at 7:26





@NurbolAlpysbayev Hi, I had a typo, I fixed the question so that foo is checking never in the conditional. Notice that the result type in Result1 is never, yet the result in Result2 is . Just curious why this is? Because it seems like they both land on in the conditional check.

– trusktr
Dec 31 '18 at 7:26













It seems to me that you are using never type completely wrong. Do you want by never to indicate that there are no items? If yes it should be done by or null. never is not for that. And I hardly can imagine that something can extend never.

– Nurbol Alpysbayev
Dec 31 '18 at 7:26







It seems to me that you are using never type completely wrong. Do you want by never to indicate that there are no items? If yes it should be done by or null. never is not for that. And I hardly can imagine that something can extend never.

– Nurbol Alpysbayev
Dec 31 '18 at 7:26















Just write your original goal and we'll sort it out easily, I think.

– Nurbol Alpysbayev
Dec 31 '18 at 7:29







Just write your original goal and we'll sort it out easily, I think.

– Nurbol Alpysbayev
Dec 31 '18 at 7:29















@NurbolAlpysbayev It's because I am doing this (stackoverflow.com/questions/53568797) and instead of using undefined I thought I would try never to see what happens, and found that the result is inconsistent, so I'm just trying to understand why. In practice, I think undefined is fine for defining what the args of the event in that other question should be, because if I actually wanted to define an arg of type undefined that wouldn't make much sense in the runtime JS code anyways.

– trusktr
Dec 31 '18 at 7:33





@NurbolAlpysbayev It's because I am doing this (stackoverflow.com/questions/53568797) and instead of using undefined I thought I would try never to see what happens, and found that the result is inconsistent, so I'm just trying to understand why. In practice, I think undefined is fine for defining what the args of the event in that other question should be, because if I actually wanted to define an arg of type undefined that wouldn't make much sense in the runtime JS code anyways.

– trusktr
Dec 31 '18 at 7:33












1 Answer
1






active

oldest

votes


















2














What you really are asking is:



type Foo = never extends never ? true : false // gives true
//but
type Bar<T> = T extends never ? true : false
type Baz = Bar<never> // not `true` as expected but `never`!


Well, I became curious on this and wondered if it has something to do with distributive conditional types.



So I changed the above code to this:



type Bar<T> = [T] extends [never] ? true : false
type Baz = Bar<never> // true as expected


Hence the answer is: You are distributing an empty union aka never and this gives a result of the distribution of an empty union (aka never): that is another empty union! Completely makes sense!



UPD: why never is an "empty union"? Well maybe this code will demonstrate it:



type Union1 = number | string | never // number | string
type Union2 = number | never // number
type Union3 = never // never aka empty union





share|improve this answer


























  • Do you mind if I also provide an answer to this ? The reason is in the PR introducing never github.com/Microsoft/TypeScript/pull/8652

    – Titian Cernicova-Dragomir
    Dec 31 '18 at 7:49











  • @TitianCernicova-Dragomir Hi Titian, I am glad that you even asked, but I am always happy to see your answers, because they always add some good value! So of course, yes! In the meantime I am adding some examples of never, of how I use it personally.

    – Nurbol Alpysbayev
    Dec 31 '18 at 7:51








  • 1





    @TitianCernicova-Dragomir Hey, why you've deleted your answer? ) I guess that means that you consider mine better? Cool then! :D But I am sorry about that)

    – Nurbol Alpysbayev
    Dec 31 '18 at 8:25






  • 1





    @trusktr It's hard to understand until you carefully read the link (in the answer) about DCT and this and do some practice or play with few examples. In turn, those eventEmitter questions are hard for me, because I events generally hard for me (and I dislike this pattern), and referencing to other questions is making it harder. My suggestion is to close this question (i.e. consider accepting my answer if it helped or after you understand it) and to move on to the next little question.

    – Nurbol Alpysbayev
    Dec 31 '18 at 10:12








  • 1





    @trusktr hack it making both side of the extends a tuple it's totally not a hack or bug, it's a feature (naked type parameter vs "clothed" see the link in the previous comment). But yes it looked like a hack for me too when I have been learning TS.

    – Nurbol Alpysbayev
    Dec 31 '18 at 10:18













Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53984650%2ftypescript-never-type-inconsistently-matched-in-conditional-type%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









2














What you really are asking is:



type Foo = never extends never ? true : false // gives true
//but
type Bar<T> = T extends never ? true : false
type Baz = Bar<never> // not `true` as expected but `never`!


Well, I became curious on this and wondered if it has something to do with distributive conditional types.



So I changed the above code to this:



type Bar<T> = [T] extends [never] ? true : false
type Baz = Bar<never> // true as expected


Hence the answer is: You are distributing an empty union aka never and this gives a result of the distribution of an empty union (aka never): that is another empty union! Completely makes sense!



UPD: why never is an "empty union"? Well maybe this code will demonstrate it:



type Union1 = number | string | never // number | string
type Union2 = number | never // number
type Union3 = never // never aka empty union





share|improve this answer


























  • Do you mind if I also provide an answer to this ? The reason is in the PR introducing never github.com/Microsoft/TypeScript/pull/8652

    – Titian Cernicova-Dragomir
    Dec 31 '18 at 7:49











  • @TitianCernicova-Dragomir Hi Titian, I am glad that you even asked, but I am always happy to see your answers, because they always add some good value! So of course, yes! In the meantime I am adding some examples of never, of how I use it personally.

    – Nurbol Alpysbayev
    Dec 31 '18 at 7:51








  • 1





    @TitianCernicova-Dragomir Hey, why you've deleted your answer? ) I guess that means that you consider mine better? Cool then! :D But I am sorry about that)

    – Nurbol Alpysbayev
    Dec 31 '18 at 8:25






  • 1





    @trusktr It's hard to understand until you carefully read the link (in the answer) about DCT and this and do some practice or play with few examples. In turn, those eventEmitter questions are hard for me, because I events generally hard for me (and I dislike this pattern), and referencing to other questions is making it harder. My suggestion is to close this question (i.e. consider accepting my answer if it helped or after you understand it) and to move on to the next little question.

    – Nurbol Alpysbayev
    Dec 31 '18 at 10:12








  • 1





    @trusktr hack it making both side of the extends a tuple it's totally not a hack or bug, it's a feature (naked type parameter vs "clothed" see the link in the previous comment). But yes it looked like a hack for me too when I have been learning TS.

    – Nurbol Alpysbayev
    Dec 31 '18 at 10:18


















2














What you really are asking is:



type Foo = never extends never ? true : false // gives true
//but
type Bar<T> = T extends never ? true : false
type Baz = Bar<never> // not `true` as expected but `never`!


Well, I became curious on this and wondered if it has something to do with distributive conditional types.



So I changed the above code to this:



type Bar<T> = [T] extends [never] ? true : false
type Baz = Bar<never> // true as expected


Hence the answer is: You are distributing an empty union aka never and this gives a result of the distribution of an empty union (aka never): that is another empty union! Completely makes sense!



UPD: why never is an "empty union"? Well maybe this code will demonstrate it:



type Union1 = number | string | never // number | string
type Union2 = number | never // number
type Union3 = never // never aka empty union





share|improve this answer


























  • Do you mind if I also provide an answer to this ? The reason is in the PR introducing never github.com/Microsoft/TypeScript/pull/8652

    – Titian Cernicova-Dragomir
    Dec 31 '18 at 7:49











  • @TitianCernicova-Dragomir Hi Titian, I am glad that you even asked, but I am always happy to see your answers, because they always add some good value! So of course, yes! In the meantime I am adding some examples of never, of how I use it personally.

    – Nurbol Alpysbayev
    Dec 31 '18 at 7:51








  • 1





    @TitianCernicova-Dragomir Hey, why you've deleted your answer? ) I guess that means that you consider mine better? Cool then! :D But I am sorry about that)

    – Nurbol Alpysbayev
    Dec 31 '18 at 8:25






  • 1





    @trusktr It's hard to understand until you carefully read the link (in the answer) about DCT and this and do some practice or play with few examples. In turn, those eventEmitter questions are hard for me, because I events generally hard for me (and I dislike this pattern), and referencing to other questions is making it harder. My suggestion is to close this question (i.e. consider accepting my answer if it helped or after you understand it) and to move on to the next little question.

    – Nurbol Alpysbayev
    Dec 31 '18 at 10:12








  • 1





    @trusktr hack it making both side of the extends a tuple it's totally not a hack or bug, it's a feature (naked type parameter vs "clothed" see the link in the previous comment). But yes it looked like a hack for me too when I have been learning TS.

    – Nurbol Alpysbayev
    Dec 31 '18 at 10:18
















2












2








2







What you really are asking is:



type Foo = never extends never ? true : false // gives true
//but
type Bar<T> = T extends never ? true : false
type Baz = Bar<never> // not `true` as expected but `never`!


Well, I became curious on this and wondered if it has something to do with distributive conditional types.



So I changed the above code to this:



type Bar<T> = [T] extends [never] ? true : false
type Baz = Bar<never> // true as expected


Hence the answer is: You are distributing an empty union aka never and this gives a result of the distribution of an empty union (aka never): that is another empty union! Completely makes sense!



UPD: why never is an "empty union"? Well maybe this code will demonstrate it:



type Union1 = number | string | never // number | string
type Union2 = number | never // number
type Union3 = never // never aka empty union





share|improve this answer















What you really are asking is:



type Foo = never extends never ? true : false // gives true
//but
type Bar<T> = T extends never ? true : false
type Baz = Bar<never> // not `true` as expected but `never`!


Well, I became curious on this and wondered if it has something to do with distributive conditional types.



So I changed the above code to this:



type Bar<T> = [T] extends [never] ? true : false
type Baz = Bar<never> // true as expected


Hence the answer is: You are distributing an empty union aka never and this gives a result of the distribution of an empty union (aka never): that is another empty union! Completely makes sense!



UPD: why never is an "empty union"? Well maybe this code will demonstrate it:



type Union1 = number | string | never // number | string
type Union2 = number | never // number
type Union3 = never // never aka empty union






share|improve this answer














share|improve this answer



share|improve this answer








edited Dec 31 '18 at 8:37

























answered Dec 31 '18 at 7:46









Nurbol AlpysbayevNurbol Alpysbayev

4,0761327




4,0761327













  • Do you mind if I also provide an answer to this ? The reason is in the PR introducing never github.com/Microsoft/TypeScript/pull/8652

    – Titian Cernicova-Dragomir
    Dec 31 '18 at 7:49











  • @TitianCernicova-Dragomir Hi Titian, I am glad that you even asked, but I am always happy to see your answers, because they always add some good value! So of course, yes! In the meantime I am adding some examples of never, of how I use it personally.

    – Nurbol Alpysbayev
    Dec 31 '18 at 7:51








  • 1





    @TitianCernicova-Dragomir Hey, why you've deleted your answer? ) I guess that means that you consider mine better? Cool then! :D But I am sorry about that)

    – Nurbol Alpysbayev
    Dec 31 '18 at 8:25






  • 1





    @trusktr It's hard to understand until you carefully read the link (in the answer) about DCT and this and do some practice or play with few examples. In turn, those eventEmitter questions are hard for me, because I events generally hard for me (and I dislike this pattern), and referencing to other questions is making it harder. My suggestion is to close this question (i.e. consider accepting my answer if it helped or after you understand it) and to move on to the next little question.

    – Nurbol Alpysbayev
    Dec 31 '18 at 10:12








  • 1





    @trusktr hack it making both side of the extends a tuple it's totally not a hack or bug, it's a feature (naked type parameter vs "clothed" see the link in the previous comment). But yes it looked like a hack for me too when I have been learning TS.

    – Nurbol Alpysbayev
    Dec 31 '18 at 10:18





















  • Do you mind if I also provide an answer to this ? The reason is in the PR introducing never github.com/Microsoft/TypeScript/pull/8652

    – Titian Cernicova-Dragomir
    Dec 31 '18 at 7:49











  • @TitianCernicova-Dragomir Hi Titian, I am glad that you even asked, but I am always happy to see your answers, because they always add some good value! So of course, yes! In the meantime I am adding some examples of never, of how I use it personally.

    – Nurbol Alpysbayev
    Dec 31 '18 at 7:51








  • 1





    @TitianCernicova-Dragomir Hey, why you've deleted your answer? ) I guess that means that you consider mine better? Cool then! :D But I am sorry about that)

    – Nurbol Alpysbayev
    Dec 31 '18 at 8:25






  • 1





    @trusktr It's hard to understand until you carefully read the link (in the answer) about DCT and this and do some practice or play with few examples. In turn, those eventEmitter questions are hard for me, because I events generally hard for me (and I dislike this pattern), and referencing to other questions is making it harder. My suggestion is to close this question (i.e. consider accepting my answer if it helped or after you understand it) and to move on to the next little question.

    – Nurbol Alpysbayev
    Dec 31 '18 at 10:12








  • 1





    @trusktr hack it making both side of the extends a tuple it's totally not a hack or bug, it's a feature (naked type parameter vs "clothed" see the link in the previous comment). But yes it looked like a hack for me too when I have been learning TS.

    – Nurbol Alpysbayev
    Dec 31 '18 at 10:18



















Do you mind if I also provide an answer to this ? The reason is in the PR introducing never github.com/Microsoft/TypeScript/pull/8652

– Titian Cernicova-Dragomir
Dec 31 '18 at 7:49





Do you mind if I also provide an answer to this ? The reason is in the PR introducing never github.com/Microsoft/TypeScript/pull/8652

– Titian Cernicova-Dragomir
Dec 31 '18 at 7:49













@TitianCernicova-Dragomir Hi Titian, I am glad that you even asked, but I am always happy to see your answers, because they always add some good value! So of course, yes! In the meantime I am adding some examples of never, of how I use it personally.

– Nurbol Alpysbayev
Dec 31 '18 at 7:51







@TitianCernicova-Dragomir Hi Titian, I am glad that you even asked, but I am always happy to see your answers, because they always add some good value! So of course, yes! In the meantime I am adding some examples of never, of how I use it personally.

– Nurbol Alpysbayev
Dec 31 '18 at 7:51






1




1





@TitianCernicova-Dragomir Hey, why you've deleted your answer? ) I guess that means that you consider mine better? Cool then! :D But I am sorry about that)

– Nurbol Alpysbayev
Dec 31 '18 at 8:25





@TitianCernicova-Dragomir Hey, why you've deleted your answer? ) I guess that means that you consider mine better? Cool then! :D But I am sorry about that)

– Nurbol Alpysbayev
Dec 31 '18 at 8:25




1




1





@trusktr It's hard to understand until you carefully read the link (in the answer) about DCT and this and do some practice or play with few examples. In turn, those eventEmitter questions are hard for me, because I events generally hard for me (and I dislike this pattern), and referencing to other questions is making it harder. My suggestion is to close this question (i.e. consider accepting my answer if it helped or after you understand it) and to move on to the next little question.

– Nurbol Alpysbayev
Dec 31 '18 at 10:12







@trusktr It's hard to understand until you carefully read the link (in the answer) about DCT and this and do some practice or play with few examples. In turn, those eventEmitter questions are hard for me, because I events generally hard for me (and I dislike this pattern), and referencing to other questions is making it harder. My suggestion is to close this question (i.e. consider accepting my answer if it helped or after you understand it) and to move on to the next little question.

– Nurbol Alpysbayev
Dec 31 '18 at 10:12






1




1





@trusktr hack it making both side of the extends a tuple it's totally not a hack or bug, it's a feature (naked type parameter vs "clothed" see the link in the previous comment). But yes it looked like a hack for me too when I have been learning TS.

– Nurbol Alpysbayev
Dec 31 '18 at 10:18







@trusktr hack it making both side of the extends a tuple it's totally not a hack or bug, it's a feature (naked type parameter vs "clothed" see the link in the previous comment). But yes it looked like a hack for me too when I have been learning TS.

– Nurbol Alpysbayev
Dec 31 '18 at 10:18




















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53984650%2ftypescript-never-type-inconsistently-matched-in-conditional-type%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Monofisismo

Angular Downloading a file using contenturl with Basic Authentication

Olmecas