-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
feat(lib/es2015): Add typed overloads to Reflect
#35608
Conversation
src/lib/es2015.reflect.d.ts
Outdated
* @param argumentsList An array of argument values to be passed to the function. | ||
*/ | ||
function apply<T, A extends any[], R>(target: (this: T, ...args: A) => R, thisArgument: T, argumentsList: A): R; | ||
function apply(target: (...args: any) => any, thisArgument: any, argumentsList: ArrayLike<any>): any; |
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.
This second overload will just be picked by the compiler whenever anything fails to be accepted by the first overload, so this doesn't really add strictness. Better autocomplete, I guess.
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.
Unfortunately, this is needed to be able to pass the arguments
object.
src/lib/es2015.reflect.d.ts
Outdated
* @param newTarget The constructor to be used as the `new.target` object. | ||
*/ | ||
function construct<A extends any[], R>(target: new (...args: A) => R, argumentsList: A, newTarget?: new (...args: any) => any): R; | ||
function construct(target: new (...args: any) => any, argumentsList: ArrayLike<any>, newTarget?: new (...args: any) => any): any; |
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.
Same here, the second overload makes the first one useless 😢
6901942
to
ea136c0
Compare
This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise. |
ea136c0
to
902a77d
Compare
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.
This seems like a reasonable improvement that wouldn't break anything obvious because it leaves the originals behind as overloads. I did a quick sample of usage and Reflect
is used sparingly across many prominent packages, so I think we'd notice problems after merging if there were going to be any.
However, I'd like to get the opinion of one other team member before merging, since lib changes nearly always have hidden gotches. @andrewbranch or @rbuckton can you give your opinion?
This adds typed overloads to
Reflect
, similar to whatstrictBindCallApply
does.I’ve also corrected the type of(extracted into #41987)getPrototypeOf(…)
andsetPrototypeOf(…)
.Depends on:
Reflect.enumerate(…)
#38967 (merged)Reflect
methods #41987 (merged)