In the sense that these are existing terms of art from functional programming, they inherit the meaning of being non-mutating.
If we did consider changing the name of one, I’d prefer if we considered all of them at once (so the various bike sheds would be painted in complementary colors) -DW > On Apr 7, 2016, at 12:12 PM, Dave Abrahams via swift-evolution > <swift-evolution@swift.org> wrote: > > > on Thu Apr 07 2016, Arsen Gasparyan <swift-evolution@swift.org> wrote: > >> Hey guys, >> >> The 'flatten()' method didn't get the Swift 3 API renaming treatment it >> should >> have, to go along with reversed, sorted, joined, etc. >> As I see Dmitri Gribenko already agree with it but we still have to discuss >> it >> here. So what do you think? >> >> Implementation: https://github.com/apple/swift/pull/2038 > > I am agnostic on this, but should explain the rationale for the current > name. It wasn't overlooked. We kept flatten as is because it is part of > a suite of methods that are terms of art from functional programming > (map, filter, flatMap, reduce) that don't follow the naming guidelines > but we are nonetheless leaving alone. The fact that the semantics of > flatMap can only be sensibly described in terms of map and flatten > reinforces this rationale. > > If we want to change flatten, we should decide whether this is a > principled change, and if so, what the principle is. If it's a change > simply because “flatten() feels weird,” that's OK too, but we should > understand what we're doing and why. > > -- > Dave > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution