TypeScript never type inconsistently matched in conditional type?
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
|
show 1 more comment
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
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 thatfoo
is checkingnever
in the conditional. Notice that the result type inResult1
isnever
, yet the result inResult2
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 usingnever
type completely wrong. Do you want bynever
to indicate that there are no items? If yes it should be done byor
null
.never
is 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 usingundefined
I thought I would trynever
to see what happens, and found that the result is inconsistent, so I'm just trying to understand why. In practice, I thinkundefined
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
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
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
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 thatfoo
is checkingnever
in the conditional. Notice that the result type inResult1
isnever
, yet the result inResult2
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 usingnever
type completely wrong. Do you want bynever
to indicate that there are no items? If yes it should be done byor
null
.never
is 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 usingundefined
I thought I would trynever
to see what happens, and found that the result is inconsistent, so I'm just trying to understand why. In practice, I thinkundefined
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
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 thatfoo
is checkingnever
in the conditional. Notice that the result type inResult1
isnever
, yet the result inResult2
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 usingnever
type completely wrong. Do you want bynever
to indicate that there are no items? If yes it should be done byor
null
.never
is 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 usingundefined
I thought I would trynever
to see what happens, and found that the result is inconsistent, so I'm just trying to understand why. In practice, I thinkundefined
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
|
show 1 more comment
1 Answer
1
active
oldest
votes
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
Do you mind if I also provide an answer to this ? The reason is in the PR introducingnever
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 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 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
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
});
}
});
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
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
Do you mind if I also provide an answer to this ? The reason is in the PR introducingnever
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 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 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
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
Do you mind if I also provide an answer to this ? The reason is in the PR introducingnever
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 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 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
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
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
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 introducingnever
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 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 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
Do you mind if I also provide an answer to this ? The reason is in the PR introducingnever
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 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 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
|
show 4 more comments
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.
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
foo
is checkingnever
in the conditional. Notice that the result type inResult1
isnever
, yet the result inResult2
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 bynever
to indicate that there are no items? If yes it should be done byor
null
.never
is 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
undefined
I thought I would trynever
to see what happens, and found that the result is inconsistent, so I'm just trying to understand why. In practice, I thinkundefined
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