Simplify types of array/slice and array/base/slice via use of generic type parameter

[Planeshifter]

Description

What is the purpose of this pull request?

This pull request:

• simplifies the types of array/slice and array/base/slice through the use of generic type parameters.

Related Issues

Does this pull request have any related issues?

No.

Questions

Any questions for reviewers of this pull request?

No.

Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

No.

Checklist

Please ensure the following tasks are completed before submitting this pull request.

• Read, understood, and followed the contributing guidelines.

---

@stdlib-js/reviewers

[kgryte]

I think we lost some info here. Namely, if T is a collection without a slice method, we always return a "generic" array having elements of the same type. The prior definition was a fall back definition for "unknown" collections and "generic" arrays. We can probably do better by defining an interface which extends Collection and has a slice method conforming to a particular signature. In that case, T in and T out. Otherwise, for a collection without a slice method, we return a "generic" array having elements of type U.

[Planeshifter]

@kgryte I reverted back to the prior definitions for a generic collection. We also have to do this as my proposed type broke down for tuples (say [1,2,3] as const), which would incorrectly be set as the return type irrespective of what was sliced off.

But we do have another issue that was present before, namely that the definition doesn't work for strings, as it incorrectly asserts that the return value will be an array of strings in this case, though it is just a string. Should we handle this, even though the package is in the array namespace?

[kgryte]

In my mind, that the function does not apply to strings is fine with me and part of the original reason why I typed it as Collection, rather than ArrayLike. For users wanting to slice strings, they'd be better off using a dedicated @stdlib/string/slice package.

[Planeshifter]

@kgryte Makes sense, although I believe strings do fall under our Collections as well, right?

[kgryte]

Actually, no.

See

stdlib/tools/docs/jsdoc/typedefs/objects.js

Line 54 in 4315e33

* A collection, which is defined as either an array, typed array, or an array-like object (excluding strings and functions).

and

stdlib/lib/node_modules/@stdlib/assert/is-collection/lib/main.js

Line 45 in 4315e33

typeof value === 'object' &&

.

[kgryte]

Strings do fall under the TypeScript definition (

stdlib/lib/node_modules/@stdlib/types/index.d.ts

Line 595 in 4315e33

type Collection<T = any> = Array<T> | TypedArray | ArrayLike<T>; // eslint-disable-line @typescript-eslint/no-explicit-any

); but this was because we, I believe, could not easily type an "array-like object".

[kgryte]

Things may have changed, but IIRC it may have been influenced by TypeScript 2.1 capabilities.

[kgryte]

@Planeshifter Thanks for the POC. Overall, this will be an improvement. I think we can improve the declarations a bit more to account for implementation details. Once resolved, this should be ready for merge.

[kgryte]

Would it make sense to use the interface approach I mentioned previously, or should we be content with typing like this? Atm, this will return incorrect results for specialized constructors having a slice method which are not captured by TypedArray | ComplexTypedArray. Granted, the previous declarations also did not capture this case, but we could go ahead and correct here.

[Planeshifter]

@kgryte We should merge this PR without the proposed change as I am not getting it to work properly with tuple types. Have some work-in-progress stuff we can discuss but this is quite complicated and would also require some opaque typing, I believe.

[kgryte]

Okay. We should create a TODO to follow-up.

[kgryte]

@Planeshifter Thanks for the updates. A couple of the examples are incorrect, and I have a question about how we can retain type specificity when an input array has a slice method.

[kgryte]

LGTM. Thanks, @Planeshifter!