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
typescript
asked Dec 31 '18 at 7:13
trusktrtrusktr
17k30116162
|
show 1 more comment
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
typescript
asked Dec 31 '18 at 7:13
trusktrtrusktr
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 thatfoois checkingneverin the conditional. Notice that the result type inResult1isnever, yet the result inResult2is. Just curious why this is? Because it seems like they both land onin the conditional check.
– trusktr
Dec 31 '18 at 7:26
It seems to me that you are usingnevertype completely wrong. Do you want byneverto indicate that there are no items? If yes it should be done byornull.neveris not for that. And I hardly can imagine that something can extendnever.
– 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 usingundefinedI thought I would tryneverto see what happens, and found that the result is inconsistent, so I'm just trying to understand why. In practice, I thinkundefinedis 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
|
show 1 more comment
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
typescript
asked Dec 31 '18 at 7:13
trusktrtrusktr
17k30116162
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
typescript
asked Dec 31 '18 at 7:13
trusktrtrusktr
17k30116162
asked Dec 31 '18 at 7:13
trusktrtrusktr
17k30116162
edited Dec 31 '18 at 7:28
trusktr
asked Dec 31 '18 at 7:13
trusktrtrusktr
17k30116162
asked Dec 31 '18 at 7:13
trusktrtrusktr
17k30116162
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 thatfoois checkingneverin the conditional. Notice that the result type inResult1isnever, yet the result inResult2is. Just curious why this is? Because it seems like they both land onin the conditional check.
– trusktr
Dec 31 '18 at 7:26
It seems to me that you are usingnevertype completely wrong. Do you want byneverto indicate that there are no items? If yes it should be done byornull.neveris not for that. And I hardly can imagine that something can extendnever.
– 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 usingundefinedI thought I would tryneverto see what happens, and found that the result is inconsistent, so I'm just trying to understand why. In practice, I thinkundefinedis 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
|
show 1 more comment
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 thatfoois checkingneverin the conditional. Notice that the result type inResult1isnever, yet the result inResult2is. Just curious why this is? Because it seems like they both land onin the conditional check.
– trusktr
Dec 31 '18 at 7:26
It seems to me that you are usingnevertype completely wrong. Do you want byneverto indicate that there are no items? If yes it should be done byornull.neveris not for that. And I hardly can imagine that something can extendnever.
– 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 usingundefinedI thought I would tryneverto see what happens, and found that the result is inconsistent, so I'm just trying to understand why. In practice, I thinkundefinedis 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 – 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 – 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 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 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
|
show 1 more comment
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
answered Dec 31 '18 at 7:46
Nurbol AlpysbayevNurbol Alpysbayev
4,0761327
Do you mind if I also provide an answer to this ? The reason is in the PR introducingnevergithub.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 ofnever, 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
@trusktrhack it making both side of the extends a tupleit'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
|
show 4 more comments
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
answered Dec 31 '18 at 7:46
Nurbol AlpysbayevNurbol Alpysbayev
4,0761327
Do you mind if I also provide an answer to this ? The reason is in the PR introducingnevergithub.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 ofnever, 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
@trusktrhack it making both side of the extends a tupleit'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
|
show 4 more comments
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
answered Dec 31 '18 at 7:46
Nurbol AlpysbayevNurbol Alpysbayev
4,0761327
Do you mind if I also provide an answer to this ? The reason is in the PR introducingnevergithub.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 ofnever, 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
@trusktrhack it making both side of the extends a tupleit'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
|
show 4 more comments
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
answered Dec 31 '18 at 7:46
Nurbol AlpysbayevNurbol Alpysbayev
4,0761327
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
answered Dec 31 '18 at 7:46
Nurbol AlpysbayevNurbol Alpysbayev
4,0761327
edited Dec 31 '18 at 8:37
answered Dec 31 '18 at 7:46
Nurbol AlpysbayevNurbol Alpysbayev
4,0761327
answered Dec 31 '18 at 7:46
Nurbol AlpysbayevNurbol Alpysbayev
4,0761327
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 introducingnevergithub.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 ofnever, 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
@trusktrhack it making both side of the extends a tupleit'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
|
show 4 more comments
Do you mind if I also provide an answer to this ? The reason is in the PR introducingnevergithub.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 ofnever, 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
@trusktrhack it making both side of the extends a tupleit'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
|
show 4 more comments
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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
foois checkingneverin the conditional. Notice that the result type inResult1isnever, yet the result inResult2is. Just curious why this is? Because it seems like they both land onin the conditional check.– trusktr
Dec 31 '18 at 7:26
It seems to me that you are using
nevertype completely wrong. Do you want byneverto indicate that there are no items? If yes it should be done byornull.neveris not for that. And I hardly can imagine that something can extendnever.– 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
undefinedI thought I would tryneverto see what happens, and found that the result is inconsistent, so I'm just trying to understand why. In practice, I thinkundefinedis 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