-
Notifications
You must be signed in to change notification settings - Fork 12.9k
Allowed tuples to have both named and anonymous members #53356
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
Changes from all commits
b7816ea
2c316ce
d246ce9
c5efef9
9859f6a
99c4a01
c3c2da3
c994d4b
31f493a
df397a7
bf4b8cb
3431d24
796ec06
ffcfc79
72ad400
1e578a9
6a7fdd1
88eadca
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -6430,7 +6430,7 @@ export interface TupleType extends GenericType { | |
hasRestElement: boolean; | ||
combinedFlags: ElementFlags; | ||
readonly: boolean; | ||
labeledElementDeclarations?: readonly (NamedTupleMember | ParameterDeclaration)[]; | ||
labeledElementDeclarations?: readonly (NamedTupleMember | ParameterDeclaration | undefined)[]; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. [Breaking API Change] Is this the right choice to make? One alternative could be to rename it to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Renaming it doesn't feel like a good idea compared to this; I assume that this array is indexed such that there are empty spaces where there are no names? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
To the best of my knowledge - yes. There are a couple of places in this PR where it seems to be handled this way There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What would the alternative be if not an array with missing names? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think that most implementations that would include keeping I think the current structure of this object makes the most sense but if you consider it to be too big of a breaking change then I think a different property should be added when mixed labels are involved and this one should be kept as There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As in, this array seems to be the only one in the interface which actually describes each element; if we were to keep this array without making elements undefined, then the only thing I can think is that all of the named members gets smooshed up together, except now their indexes are lost. So, it seems to me that the change in the PR is the least breaky option when we're now saying that something can potentially be undefined, because otherwise someone may iterate over this list thinking they're seeing everything, right? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I was responding to exactly that but perhaps I wasn't super clear. Should I try to rephrase my original answer?
yeah, that would be IMHO bad - I mentioned that here: "Even if you somehow omit undefined positions you still end up with a .length mismatch between those and other properties and that would be rather disastrous.". But right now one alternative option comes to my mind - the missing labels could be prefilled with some defaults. You already generate such things for function parameters and stuff at times, like There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I know we generate synthetic nodes for names for stuff like declaration emit, but do we commonly store them in the types? (I genuinely don't know the answer!) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't know that either and perhaps you don't ever do that right now. I prefer to leave those optional members as There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we're agreeing? I think I too prefer to make them |
||
} | ||
|
||
export interface TupleTypeReference extends TypeReference { | ||
|
Uh oh!
There was an error while loading. Please reload this page.