[biddlesby]

This strikes me as a bit pessimistic. I think you are mostly against _bad_ standards than standards per se.

If the consortium does its job well it will produce a good standard that all the major libraries like: from a UX as well as a performance viewpoint.

If it produces a bad standard, all that will happen is that nobody will sign up. No libraries are going to be _forced_ to do anything.

[mlthoughts2018]

That’s fair except I’d say even good standards can cause a big slowdown in feature releases, and not everyone values the adherence to the standard as much as the features. It still seems better to just spin out the standard into a set of optional adapters and let library maintainers and users pick their own trade-offs in terms of when to adopt breaking changes, how / whether to smooth over idiosyncrasies across multiple libraries.

Even a good standard has costs and this particular case does not seem like it has good arguments in favor of a wide standard, but many arguments against it.

[westurner]

No, it's easy for library maintainers to offer a compat API in addition to however else they feel they need to differentiate and optimize the interfaces for array operations. People can contribute such APIs directly to libraries once instead of creating many conditionals in every library-utilizing project or requiring yet another dependency on an adapter / facade package that's not kept in sync with the libraries it abstracts.

If a library chooses to implement a spec compatability API, they do that once (optimally, as compared with somebody's hackish adapter facade which has very little comprehension of each library's internals) and everyone else's code doesn't need to have conditionals.

Each of L libraries implements a compat API: O(L)

Each of U library utilizers implements conditionals for every N places arrays are utilized: O(U x N_)

Each of U library utilizers uses the common denominator compat API: O(U)

L < U < (L + U) < (U x N_)