-
Notifications
You must be signed in to change notification settings - Fork 12.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add empty tuple type #14646
Add empty tuple type #14646
Conversation
src/compiler/checker.ts
Outdated
return !!getPropertyOfType(type, "0") || isEmptyTupleType(type); | ||
} | ||
|
||
function isEmptyTupleType(type: Type): boolean { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you should be to use ===
directly, so I think you should drop isEmptyTupleType
and just add || type === emptyTupleType
on line 8914
@@ -17115,10 +17118,7 @@ namespace ts { | |||
|
|||
function checkTupleType(node: TupleTypeNode) { | |||
// Grammar checking | |||
const hasErrorFromDisallowedTrailingComma = checkGrammarForDisallowedTrailingComma(node.elementTypes); | |||
if (!hasErrorFromDisallowedTrailingComma && node.elementTypes.length === 0) { | |||
grammarErrorOnNode(node, Diagnostics.A_tuple_type_element_list_cannot_be_empty); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can delete this error from diagnosticsMessages.json since this is the only usage.
var et0 = et[0]; // never | ||
var et0: never; | ||
|
||
et = []; // Ok |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you add this same check in a new file, something like tupleTypesStrictNullCheck.ts, with the first line // @strictNullChecks: true
to turn on strict null checks?
@sandersn Your comments are already reflected |
if (elementTypes.length) { | ||
return createTupleType(elementTypes); | ||
} | ||
return createTupleType(elementTypes); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you should update the createTupleType
function to return the emptyTupleType
singleton if elementTypes
is empty.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. We need to make the condition persistent over future updates. A fix is pushed!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. @RyanCavanaugh or @ahejlsberg can you take a look too?
src/compiler/checker.ts
Outdated
@@ -6209,7 +6210,13 @@ namespace ts { | |||
return tupleTypes[arity] || (tupleTypes[arity] = createTupleTypeOfArity(arity)); | |||
} | |||
|
|||
function createTupleType(elementTypes: Type[]) { | |||
function createTupleType(elementTypes: Type[]): TypeReference { | |||
// We have to ensure that we get same instance for empty tuple type, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
getTupleTypeOfArity
caches the resulting tuple type, so not sure why we need special handling here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
usage of getTupleTypeOfArity should be sufficient
I've made an attempt to revive this PR taking into account the requested changes at #17762. |
@tycho01 oh, great! but my bad! I left this PR untouched for so long time and was even unnoticed the update on the original issue until today. I appreciate you reused my code! Thanks! Just wondering. Are you going to update them further and implement the additional restrictions you mentioned in #13126 (comment) ? |
@lefb766: right, I hadn't included those in there. To answer by sub-topic there:
|
@tycho01 Thanks for explaining. I see, you have another PR. It turns out it will be harder to find difference between #17762 and this one if I happen to solve the conflict. Your investigation on the sup-topic looks interesting though. Nice work. |
@tycho01 Fair point. I'll continue this work. Sorry for bothering you and others. |
@mhegazy: conflict aside, is there more that could be done to improve this PR? |
Thanks for your contribution. This PR has not been updated in a while and cannot be automatically merged at the time being. For housekeeping purposes we are closing stale PRs. If you'd still like to continue working on this PR, please leave a message and one of the maintainers can reopen it. |
Fixes #13126
Open question: should a non-empty tuple be assignable to []?
People may think it should be, given that you can assign
[number, string]
to[number]
.However, the index signature of [] which is
never
blocks such assignment.I think this isn't going to be a problem at least for now before variadic tuples (#5453) lands.
If you need common type of all tuples, you can simply use
{}[]
orany[]
.Is there any other problemic scenario?
Related discussion: #6229