Array.prototype.shallowFlatten

[victornpb]

Why not Array.prototype.flatten with infinite depth and Array.prototype.shallowFlatten with 1 depth?

[jacktuck]

or flip it and do flatten and flattenDeep ? (that'd be my preference)

[ljharb]

The web compatibility issue isn’t with the depth; “flatten” as a name isn’t an option no matter the default depth.

[pygy]

Why can't this proposal match the MooTools flatten implementation? Are there multiple pre-existing versions of Array.prototype.flatten out there that are mutually incompatible?

[ljharb]

The issue isn’t matching the implementation; it’s an issue with enumerability. MooTools copies enumerable methods off of Array.prototype (all the ones it installed) to its Element.prototype.

The name “flatten” is unavailable as long as there are still sufficient websites out there using MooTools. If the name becomes available, this proposal would go in as-is; so any change would have to be solely to avoid the name “flatten”.

[pygy]

Early versions (v1.1 and v1.2) also seem to rely on the truthiness of methods to preserve the original or provide their own version.

Couldn't we make flatten falsy (like document.all) and non-enumerable (unless overwritten)?

In other words, implement it so that MooTools will not see the native version and will overrule it?

[ljharb]

Nobody on the committee is likely to have an appetite to add another ULEO like document.all, but the issue is that it has to be enumerable, or, would have to have a setter on it that made it enumerable when assigned, rather than being a data property.

I don’t think any given name is worth that kind of complexity.

[pygy]

ULEO: undefined-like exotic object

Actually, I think that flatMap is worth it. It's already widely adopted in the JS functional community, and it is a core function.

I understand that the committee isn't overjoyed with the perspective of another hack, but, provided that it would provide devs with the best name possible without breaking the Web, I would appreciate if you could pinch your collective nose and go for it anyway.

[bakkot]

I think the sort of hacks required to make this work would very much not be worth it, especially given the possibility of choosing another name for .flatten. Slightly better API names are really, really not the sort of thing which justify changing the core semantics of the language. Besides, it wouldn't even necessarily imply choosing another name for .flatMap.

Though also, .chain is also widely adopted as a name for what this proposal calls .flatMap, so someone isn't going to get the name they're used to.

[Pajn]

I don’t think any given name is worth that kind of complexity.

I think any good name is worth that. The "enumerable after set" hack can be removed from the standard when MooTools have died off. Setting Array.prototype.flatten can even print a warning to the console so that developers know that this behaviour is intended to be removed asap.

Changing from a bad name to a good name will never be possible as everything will depend on the bad name.

Just to be clear: I'm not saying that all names except for one is bad. Array.prototype.contains is a great example of how another name can be good (slight disadvantage initially but same over time) but with so many proposals of (IMO) bad names suggests that flatten is hard to replace. flatMap is easier with many precedents but flatten mostly has concatAll.

[ljharb]

It also has “flat”.

[pygy]

@bakkot Actually, yes, .chain would also work, but it looks like at least some people in the committee (@ljharb and @domenic) want both methods to share the same root, and anything but .flatMap will sound ridiculous.

IMO the common root should not be a hard constrain.

[ognus]

Since JS is evolving into "compiled" language, how about just use any name committee sees fit (squast(), nativeFlatten()) and have a babel plugin provide flatten() that will be transpiled to it's "native" counterpart. What do you think?

Agree that flatten and flatMap are the most obvious (the best) names, but looks like we might need to make some sacrifices :/ I think people will adjust anyway.

[ljharb]

@ognus JS is not being designed as if it is “evolving” into a compiled language (i don’t agree with that claim); and babel can’t reliably transform prototype methods anyways.

[ognus]

@ljharb Yes, I see you point. Actually what babel does with it is not that relevant, what I mostly meant to say is that we should not worry that much about choosing different name then flatten, lets pick one and move on. Although I really do understand the frustration, even more that this is not the first time (includes?).

[littledan]

Note about Babel: Polyfills are provided by the babel-polyfill module, which is basically an alias for @zloirock's core-js . We should talk more about core-js (or es-shim, or...) than Babel when discussing library functions.

[babakness]

chain is consistent with the community consensus.

https://github.com/fantasyland/fantasy-land

flatMap is descriptive

[pronebird]

Was there a research that identified the high demand among developers for Array.flatten in the first place or was it proposed only because flatMap internally relies on it?

[ljharb]

There is a massive demand for flatten in the first place: https://github.com/search?utf8=✓&q=%5B%5D.concat.apply&type=Code for a very high-level search.

[iddan]

Why can't flatMap and flatten discussed separately? I mean, I think we can find another name to flatten even though I think it sucks that a library will put a flag on a method for the whole community but I really want to see flatMap out there and flatten could be flat or whatever.

[ljharb]

This proposal is stage 4, with flat and flatMap.