Skip to content

Add --strictObjectIterables (bikeshed): exclude primitive (string) from Iterable typesΒ #59676

Open
@petamoriken

Description

πŸ” Search Terms

"iterable object", "string"

βœ… Viability Checklist

⭐ Suggestion

At the TC39 meeting in 2024-07, it was decided that Iterable expects objects.

Reject primitives in iterable-taking positions

Any time an iterable or async-iterable value (a value that has a Symbol.iterator or Symbol.asyncIterator method) is expected, primitives should be treated as if they were not iterable. Usually, this will mean throwing a TypeError. If the user provides a primitive wrapper Object such as a String Object, however, it should be treated like any other Object.

Although primitive Strings are default iterable (String.prototype has a Symbol.iterator method which enumerates code points), it is now considered a mistake to iterate a String without specifying whether the String is providing an abstraction over code units, code points, grapheme clusters, or something else.

NB: This convention is new as of 2024, and most earlier parts of the language do not follow it. In particular, positional destructuring (both binding and assignment), array spread, argument spread, for-of loops, yield *, the Set and AggregateError constructors, Object.groupBy, Map.groupBy, Promise.all, Promise.allSettled, Promise.any, Promise.race, Array.from, the static from methods on typed array constructors, and Iterator.from (Stage 3 at time of writing) all accept primitives where iterables are expected.

https://github.com/tc39/how-we-work/blob/main/normative-conventions.md#reject-primitives-in-iterable-taking-positions

To follow this decision, the Iterable and string types should be separated, and APIs that accept both types should be required to explicitly specify Iterable<any> | string. Since this would be a breaking change, how about adding a new --strictObjectIterables (bikeshed) option?

In practice, the upcoming ReadableStream.from will accept Iterable<any> and AsyncIterable<any>, but will be restricted to objects. whatwg/streams#1310

πŸ“ƒ Motivating Example

Enabling the --strictObjectIterables option raises a type error in the following example:

const iterable: Iterable<any> = "string";

πŸ’» Use Cases

  1. What do you want to use this for?

    Used for ReadableStream.from and other APIs to be added in the future.

  2. What shortcomings exist with current approaches?

    Iterable object and string are not distinguished by default.

  3. What workarounds are you using in the meantime?

    Maybe Iterable<any> & object can reject string.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Labels

    Needs ProposalThis issue needs a plan that clarifies the finer details of how it could be implemented.SuggestionAn idea for TypeScript

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions