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@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@swift.org> wrote:

On Apr 15, 2016, at 10:17 AM, Антон Жилин via swift-evolution 
<swift-evolution@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@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

Reply via email to