Rename flatten to flat

[Kerrick]

Benefits: It feels a bit more natural to have flat + map = flatMap than flatten + map = flatMap; It won't clobber old incompatible prototype monkey-patches; and it is shorter.

[ljharb]

I think this is a fine name suggestion, but i don’t agree at all with your rationale. There’s no correlation to what makes an array method a mutator method or not.

List of verb-based Array prototype methods that do not modify the array in-place:

• map
• filter
• reduce
• reduceRight
• slice
• concat
• find
• findIndex

[Kerrick]

@ljharb Fair enough. Should I edit the verb justification out of the PR description and just leave the name change?

As a side note I had always considered map, filter, and slice to be nouns. For example, "create a slice of the array." That would explain why I thought verbs were more often for mutations :)

[ljharb]

The conflation of verbs and nouns is a common naming issue :-) It’s probably best to strikethru or remove that justification, yes, but that’s up to you.

[Kerrick]

For future readers, here is what the original comment had said:

Because verb-based Array prototype methods usually imply altering the array in-place rather than returning a changed copy of the array, and because the proposed prototype flatten method returns a new array without mutating the existing array, I propose we change from a verb to a similar adjective. In this PR I chose flat but any non-verb would do.

List of verb-based Array prototype methods that modify the array in-place:

• sort
• reverse
• fill
• splice
• pop
• push
• shift
• unshift
• copyWithin

[pygy]

flattened could also work.

[bakkot]

flat + map = flatMap

Unfortunately it's map + flat = flatMap, unless I suppose you're thinking of + as the function composition operator.

Anyway, this seems like a fine name to me. Between slice, splice, entries, some, and forEach, it seems we have pretty much no naming convention at all, so there's nothing much lost by picking a different form of our preferred word if it gives us web-compat.

I prefer flat to flattened just because it's shorter, and to me just as obvious what it does.

[pygy]

unnest could also work, but we'd lose the flat- root common with flatMap.

[ljharb]

The two names need to be consistent; if we change one, we’d need to change the other.

[josephjunker]

collapse? It's nice to have the names be consistent but I don't see why they necessarily have to be. In Haskell and Scala the equivalent of flatMap is generalized to container types other than just arrays, and the generalized equivalent to "flatten" is called join in both of them. I don't think it would be a bad thing if JS also had different names for each.

[snoozbuster]

Can we consider flatten2? I've seen this pattern used before in other languages to extend or add functionality without breaking something exisitng; C# created an X509Certificate2 class to add breaking functionality without breaking code using X509Certificate, and Java created LayoutManager2 to extend LayoutManager for a similar reason.

[js-choi]

squash and squashMap may still be good options.

[Pajn]

To me, flat reads much more strongly as an adjective than either a noun or a verb which then makes it read as a property rather than a method.

[jacktuck]

Just to throw another name into the hat, what about unwind?

[tabatkins]

I do favor flat over flattened for shorter/spelling reasons, but flattened goes nicely with sorted from Python, if we ever add that.

[saschanaz]

unindent? because:

flat (adj.): smooth and even; without marked lumps or indentations.

and...:

[
  [
    "a",
    "b"
  ],
  [
    "c",
    "d"
  ]
];

// unindented, something like IDEs do for texts 😀
[
  "a",
  "b",
  "c",
  "d"
]

[joshburgess]

Is there a reason for avoiding chain? It's a well known synonym to flatMap and not already used, unlike other synonyms, such as bind...

[michaelficarra]

Fixed by https://github.com/tc39/proposal-flatMap/commit/093eacc7fe0906e70f7626bf6c7d6e9dfc53cce9. Thank you for your suggestion.

[ljharb]

@joshburgess chain would necessitate chainMap, and neither name makes much sense imo.

[tabatkins]

@ljharb You're misunderstanding - @joshburgess is suggesting chain for flatMap (and then, I suppose, not worrying about keeping the array-flattening operation's name close to the monadic operator).

[joshburgess]

I meant as a synonym to flatMap, not flat, so maybe this was the wrong place to post.... but regardless of whether or not it "makes sense", it's already a well known synonym for "flatMap" in various languages and even JS libraries.

[ljharb]

@tabatkins ah, thanks for clarifying.

In that case I think that doesn't address the problem of "what to name flatten" (setting aside that we already reached consensus for "flat").

[joshburgess]

Some examples:

In Ramda: https://ramdajs.com/docs/#chain

or in the context of streams https://github.com/cujojs/most/blob/master/docs/api.md#chain

Maybe, this should be a separate Issue thread?

[ljharb]

@joshburgess it's a stage 3 proposal and the name "flat" achieved consensus today. You certainly can file a separate thread, but it'd have to be a pretty compelling argument to make any change.

[puffnfresh]

A compelling reason is that it's been used as an identifier for the operation for 5 years:

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

As far as I know, much longer than flatMap has been used in JS.

[Kerrick]

Any reason why you made a fresh commit instead of merging the PR? Now it won’t show up as a contribution on my GitHub profile 😆

[ChALkeR]

@Kerrick Probably, this:

followed by a flat of depth 1

The patches are a bit different.

[ChALkeR]

@michaelficarra Btw, I personally like the version in this PR more.

Current version:

a map followed by a flatten of depth 1

What's «flatten»? :wink:

[Mouvedia]

chain for flatMap and collapse for flatten would have been explicit but somewhat inconsistent. IMHO verbs sounds better.