Skip to content
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): define TypedArray interface #47278

Closed
wants to merge 1 commit into from
Closed

feat(lib): define TypedArray interface #47278

wants to merge 1 commit into from

Conversation

mfulton26
Copy link
Contributor

Each concrete typed array type and constructor share common interfaces.

Library types can be defined extending base interfaces:

  1. higher code reuse
  2. less duplication
  3. easier maintenance (less error prone)

Closes #15402
Fixes #45198
Fixes #45199

Each concrete typed array type and constructor share common interfaces.

Library types can be defined extending base interfaces:

1. higher code reuse
2. less duplication
3. easier maintenance (less error prone)

Closes #15402
Fixes #45198
Fixes #45199
@typescript-bot
Copy link
Collaborator

The TypeScript team hasn't accepted the linked issue #15402. If you can get it accepted, this PR will have a better chance of being reviewed.

@typescript-bot typescript-bot added For Backlog Bug PRs that fix a backlog bug For Milestone Bug PRs that fix a bug with a specific milestone labels Dec 31, 2021
@ghost
Copy link

ghost commented Dec 31, 2021

CLA assistant check
All CLA requirements met.

@sandersn sandersn requested review from orta and sandersn January 14, 2022 01:21
@sandersn sandersn requested review from gabritto and removed request for orta February 25, 2022 02:31
@sandersn sandersn assigned gabritto and unassigned orta Feb 25, 2022
Copy link
Member

@gabritto gabritto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you run tests and update baselines? CI is failing for a lot of tests, so it's hard to evaluate the impact of this change. Meanwhile, I'll look deeper at the types.

Copy link
Member

@gabritto gabritto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think those changes are in the right direction. There's a few details in the types that I think should be addressed, but overall I think this is a good change.


interface Float64Array {
[Symbol.iterator](): IterableIterator<number>;
interface TypedArray<T> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should have T extends number | bigint here.

}

interface Float64ArrayConstructor {
new (elements: Iterable<number>): Float64Array;
interface TypedArrayConstructor<T, A extends TypedArray<T>> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here, I think T should extend number | bigint

from(arrayLike: Iterable<number>, mapfn?: (v: number, k: number) => number, thisArg?: any): Float32Array;
}

interface Float64Array {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think even though we have unified the interfaces, we should still declare them using the new TypedArray, like interface Float64Array extends TypedArray<number> { ... } and interface Float64ArrayConstructor extends TypedArrayConstructor<number, Float64Array> { ... }

/**
* Determines whether an array includes a certain element, returning true or false as appropriate.
* @param searchElement The element to search for.
* @param fromIndex The position in this array at which to begin searching for searchElement.
*/
includes(searchElement: number, fromIndex?: number): boolean;
includes(searchElement: T, fromIndex?: number): boolean;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor nit: there seems to be an extra leading whitespace here

@@ -1,35 +1,3 @@
interface Int8ArrayConstructor {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should still also have the old types declared, just now based on TypedArrayConstructor.


[Symbol.iterator](): IterableIterator<bigint>;

interface BigUint64Array extends TypedArray<bigint> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there are many properties missing from BigUint64Array and BigInt64Array if we declare them that way.
From skimming the properties, I think what we want is for BigInt64Array to extend from TypedArray<bigint> and from ArrayBufferView?


/**
* 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): Int8Array;
from<U>(arrayLike: ArrayLike<U>, mapfn: (v: U, k: number) => bigint, thisArg?: any): BigInt64Array;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should that not be something like:

Suggested change
from<U>(arrayLike: ArrayLike<U>, mapfn: (v: U, k: number) => bigint, thisArg?: any): BigInt64Array;
from<U>(arrayLike: ArrayLike<U>, mapfn: (v: U, k: number) => T, thisArg?: any): A;

* search starts at index 0.
*/
indexOf(searchElement: number, fromIndex?: number): number;
interface Uint8Array extends TypedArray<number> {}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same as for the bigint declaration, we should probably also extend ArrayBufferLike, I think

@sandersn
Copy link
Member

sandersn commented Jun 1, 2022

@mfulton26
Do you want to keep working on this? Otherwise I'd like to close it to reduce the number of open PRs.

@sandersn
Copy link
Member

sandersn commented Aug 1, 2022

To help with PR housekeeping, I'm going to close this PR since it's pretty old now.

@sandersn sandersn closed this Aug 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
For Backlog Bug PRs that fix a backlog bug For Milestone Bug PRs that fix a bug with a specific milestone
Projects
Archived in project
5 participants