[swift-evolution] [SR-933] Rename flatten to flattened

[Patrick Smith]

Yes, I agree. I think in the guidelines should be a recommendation for mutating methods are preferred, when nonmutating are preferred, and when to have both. If performance is a key goal of Swift, so much that it influences API design, then some details should be part of the guidelines also.
Patrick




On Sat, Apr 16, 2016 at 3:56 AM -0700, "David Rönnqvist" <swift-evolution at swift.org> wrote:










By “the big three”, are you referring to only the naming of map, filter, and reduce? 
I would also like to see a formal proposal along these lines, and possibly more. 
I also feel that the `inPlace` suffix was very clear (most important) and very much liked that it made the immutable version the default (less important). It manages to describe the distinction between `union`/`unionInPlace` and `sort`/`sortInPlace` in the name itself. To me, the `ed`/`ing` difference is much more subtle and favors people who are familiar with English grammar. One can argue that `sort` is both imperative and functional, and that because of [either side] the default should be [mutable/immutable]. Both arguments are valid. 
- David
On 15 Apr 2016, at 18:31, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:

On Apr 15, 2016, at 10:17 AM, Антон Жилин via swift-evolution <swift-evolution at swift.org> wrote:
I've already expressed these concerns, but nobody noticed, apparently. Here is it:
I think current -ed/-ing convention is ugly. It breaks syntactic correctness, experience from other languages, mathematical notation and functional idioms.

`InPlace` suffix was so far more correct in these terms. We can make anything a convention, but should we?
I liked the proposal about new naming conventions, but overlooked this change.

Many people will agree with me. This still can be reviewed until Swift 3.
If so, I will create a proposal to correct "the big three" in this.

What do you think?
I would like to see a formal proposal along these lines. My other suggestions are here.
-- E

_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160416/e637254d/attachment.html>