-
Notifications
You must be signed in to change notification settings - Fork 12.8k
allow BindingPattern in FunctionRestParameter #26017
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
allow BindingPattern in FunctionRestParameter #26017
Conversation
also add downlevel emit for the destructured rest param Part of microsoft#6275
Minor suggestion: can you put the tests in one file? Seems like they all could be there.
You can add a comment at the top of the file like // @sourcemap: true |
I merged the new tests into one file and added baselines for sourceMap generation. I don't fully understand these baselines, but they don't look too wrong to me 😄 |
@weswigham can you please review and merge |
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'm blind, object binding tests are there: Could you enable sourcemaps on the one with object binding patterns, too? Also tests for initializers and type errors for object binding patterns, too.
@weswigham can you please review again? I updated the PR according to your comment a while ago. |
Any news on this? I just ran into my first use case for it; now that there's nice tuple support I have some type aliases for tuples, it'd be nice to replace the function arguments with the existing tuple so it's updated if the tuple definition ever changes. This would allow a method to be able to take a tuple or each value of the tuple easily, since if you're passing a tuple you just use the spread operator, whereas if you're passing the individual values it just works as is. Prevents having to construct new tuples with If you're curious, here's my Real World Code ™ type HighlightSelector = [HighlightType, string | number];
// in a class
public register(component: IComponent, selector: HighlightSelector, until = ComponentEvent.Remove) {
const selectorId = this.getHighlightSelectorId(...selector);
this.highlightComponents.set(selectorId, component);
component.once(until, () => this.highlightComponents.delete(selectorId));
}
private getHighlightSelectorId(...[type, selector]: HighlightSelector) {
return `${type}:${selector}`;
}
private getHighlightComponent([type, selector]: HighlightSelector) {
if (type === HighlightType.Selector) {
return Component.get(`${selector}`);
}
return this.highlightComponents.get(this.getHighlightSelectorId(type, selector));
} |
@@ -29969,10 +29969,6 @@ namespace ts { | |||
checkGrammarForDisallowedTrailingComma(parameters, Diagnostics.A_rest_parameter_or_binding_pattern_may_not_have_a_trailing_comma); | |||
} | |||
|
|||
if (isBindingPattern(parameter.name)) { |
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.
Should this error still be there if its a object binding pattern?
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 mean something like (...{length}) => length
? The spec allows it and there are already tests to ensure type inference and downlevel emit works as expected.
Second part of #6275
Also adds downlevel emit for the destructured rest param.
I don't know if my change emits correct sourcemaps. @weswigham how do you test this stuff?