-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Incorrect constructor overload: takes only first overload, but not others #60745
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
Comments
As we can see 3rd overload:
interface Uint32ArrayConstructor {
readonly prototype: Uint32Array<ArrayBufferLike>;
new (length: number): Uint32Array<ArrayBuffer>;
new (array: ArrayLike<number>): Uint32Array<ArrayBuffer>;
new <TArrayBuffer extends ArrayBufferLike = ArrayBuffer>(buffer: TArrayBuffer, byteOffset?: number, length?: number): Uint32Array<TArrayBuffer>;
new (array: ArrayLike<number> | ArrayBuffer): Uint32Array<ArrayBuffer>;
/**
* The size in bytes of each element in the array.
*/
readonly BYTES_PER_ELEMENT: number;
/**
* Returns a new array from a set of elements.
* @param items A set of elements to include in the new array object.
*/
of(...items: number[]): Uint32Array<ArrayBuffer>;
/**
* Creates an array from an array-like or iterable object.
* @param arrayLike An array-like or iterable object to convert to an array.
*/
from(arrayLike: ArrayLike<number>): Uint32Array<ArrayBuffer>;
/**
* Creates an array from an array-like or iterable object.
* @param arrayLike An array-like or iterable object to convert to an array.
* @param mapfn A mapping function to call on every element of the array.
* @param thisArg Value of 'this' used to invoke the mapfn.
*/
from<T>(arrayLike: ArrayLike<T>, mapfn: (v: T, k: number) => number, thisArg?: any): Uint32Array<ArrayBuffer>;
}
declare var Uint32Array: Uint32ArrayConstructor; |
This isn't a bug in TS, but it's unfortunate fallout of the new feature whereby
So since the new constructors are generic, they have type parameters, and things go sideways. They wanted #59417 not to be a breaking change but I think there are these edge cases where it happens. You should probably change type IndexElementsConstructor = new (buffer: ArrayBuffer, byteOffset?: number, length?: number) =>
Uint32Array | Uint16Array | Uint8Array; to make it work again. |
Iβm experiencing same problem in ts 5.7 when extending TypedArray class like this: |
This issue has been marked as "Design Limitation" and has seen no recent activity. It has been automatically closed for house-keeping purposes. |
Now if we want type IndexElementsConstructor = Uint32ArrayConstructor | Uint16ArrayConstructor | Uint8ArrayConstructor;
let viewType: IndexElementsConstructor;
...
viewType.BYTES_PER_ELEMENT things become more complicated. |
Marking not interesting issues with "Design Limitation" is very interesting tool for solving problems, is not it, @RyanCavanaugh ? Somebody failed once long time ago, someone failed again now and we got mess, but instead of fix "we will close ticket and act like nothing happens"? |
When you union constructor types, generic signatures must match exactly. Since each constructor type in the union produces a different return type, they are excluded from the resulting set. In the long term, I can look into adding non-generic overloads for these cases, assuming its feasible to do so without introducing further breaks. In the short term, @jcalz suggestion is a good workaround. |
π Search Terms
constructor, typescript, Uint32Array, Uint16Array, Uint8Array, Uint32ArrayConstructor, Uint16ArrayConstructor, Uint8ArrayConstructor
π Version & Regression Information
β― Playground Link
https://www.typescriptlang.org/play/?target=9&ts=5.7.2#code/FAFwngDgpgBAkgOwCZQB4FEA2UC2UEgDOAwgPYKEgBOArgMYilUwC8MAqgJYEDMATAEEqVAIZgyFavUbMAPh24gAjADYho8eUq0GTGPK4EAHOrETt0pgG5gwAGY0EDTuRggolABR1SOCOXwQABVIKAAuGAQaHAAjKCoAGhg6AAtHAGsAEREQEQAhbgjTMDyaOzt4gEoYAG9gGAaYbBAYADdOKAB3EOgIxBQMbDwCEi0pXSobesbCTs4QVJhvX38EQJ6oarrGneSRQlgAdSgYgHEAGT4AJXwUKm4Acwl3VBAAOnYAOQBlOFPP9CZAD6cE+QTC012u3aXQ2rAUvEEwjEUyhUJiVCgInSqLRdH2RxOF2ut3ij2eaHeX1+-0BQO+AAkAPJXcGQtENGHdULwwzKNTIsC4jkNDFYnG2Dn4g4wY5nS43ZBkhBPcgvKk-P4A4F5ACaQXQEJFjS5cLYfJMguFIrF2OtOxQdhENEwICNxrcKSopE6kS6MHQwiYngABgAiHx+AIEDZhmCcQiRUgtalaumgoJJVO04GMllBGB6bPaoF6g1LAAkNUjq3WoQAvpUQ5UbDt65LGj5JHtMHQXTkoEhSuV4kzygcWmwACytztjHt9zADodlCpUc74B4gFLwozWzEgGhUBB+32m0LeNIILI5fLcJL43v99wrkdUMd2CcPkRPpcv4drhuKrbi2wDtkAA
π» Code
π Actual behavior
π Expected behavior
Additional information about the issue
If change code to simpler variant:
newest TS version recognizes this.
The text was updated successfully, but these errors were encountered: