[lucacasonato]

I hope the pace will accelerate. The real questions is what functions we need though. Some candidates that I would love to see are better helper functions on iterators, and Uint8Array<->base64/hex. Most of the "standard library" in most languages is related to IO, and for JS is dependant on the host (the web, Deno, Node) so not something TC39 will touch directly. Do you have ideas for standard library functions that you think are missing?

[FragenAntworten]

'enumerate', as in Python.

'clamp' and 'sortBy', as in Lodash.

Set methods for union, intersection, difference, etc.

[tempodox]

Re set operators: For completeness' sake there would have to be a way to specify how set elements are to be tested for equality.

[amitport]

'range' a-la python

[wruza]

Range a-la python is a generator and is pretty straightforward in js as is. There is no need for a complicated solution and/or as part of stdlib, imo:

  function* range(x, y) {
    while (x <= y) {yield x++}
    // or ‘<‘ if you want half-open one
  }

  for (let n of range(3, 5)){
    console.log(n)
  }

  array = [...range(3, 5)]
  console.log(array)

[amitport]

It's also straight forward to implement in python. It is common enough to be standard so people won't reinvent the wheel. And it should be available to people learning the language before they learn generators.

Array.prototype.indexOf is also pretty simple as are many core functions.

[wiredearp]

Immutable data structures are on the agenda over in https://github.com/tc39/proposal-record-tuple and I would vote for that in Deno while I have the chance.

[lucacasonato]

Yup, we'll ship them once they go Stage 3/4 (when Chrome ships them in stable).

[Zababa]

I often miss map, reduce and filter on iterators, though this is already a stage 2 proposal: https://github.com/tc39/proposal-iterator-helpers.

[lucacasonato]

This is definitely something I am interested in pushing too. Iterators have not gotten the love they deserve.

[Zababa]

That's great to hear! Congratulations and thank you for your work.

[tarjei_huse]

I miss being able to create a hash from an array in a quick way. You always end up with

let bar = [{id: zz, }, {id: y},...]

let foo = {}

bar.forEach(v => foo[v.id] = v)

I'd love to have something like:

let foo = bar.toMap(v => [v.id, v])

[keville]

const foo = bar.reduce((hash, item) => { hash[item.id] = item; return hash; }, {});

[wiredearp]

new Map([[k1,v1], [k2, v2]]) can do that. Or Object.fromEntries with the same argument.

[tarjei_huse]

Thanks!

You still need to create the middle datastructure ( [[k1,v1], [k2, v2]] ) but it is an improvement :)

[wiredearp]

Ah yes, true, you always need to map the things ID to the thing itself, so that middle data structure is actually quite annoying :)

[runarberg]

    let foo = Object.fromEntries(bar.map((v) => [v.id, v]));

[keville]

It is not necessary to create any extraneous data structures to do OP's one-liner. This creates n+1 new arrays that must be garbage-collected.

[runarberg]

Object.fromEntries takes iterable, so if you have a map from a handy iterator library you could get rid of the parent array returned from `bar.map`.

    import { map } from "my-iter-lib";
    
    Object.fromEntries(map((v) => [v.id, v], bar));

Or with the proposed iterator-helpers:

    Object.fromEntries(
      Iterator.from(bar).map((v) => [v.id, v]),
    )

However the inner arrays are harder to get rid of... In fact even OP’s oneliner defines the inner arrays. I would hope there were some engine optimizations though which could minimize their footprint.

[keville]

Please see my other comment in this thread for the `reduce`-based solution that requires no extra data structures. They're not that hard to get rid of!

[amitport]

'zip' a-la python

[lucacasonato]

I have often needed this too. Noted.

[amitport]

'reversed' a-la python

[lucacasonato]

Currently in stage 2 as `Array.prototype.toReversed`: https://github.com/tc39/proposal-change-array-by-copy

[amitport]

Nice, I didn't know about that, but in any case note that IMO it should be part of the Iterable protocol. Also note that the proposal above creates a copy on reverse AFAIKT.