[swift-evolution] [Review] SE-0023 API Design Guidelines

[Dave Abrahams]

on Sun Jan 24 2016, "charles-AT-charlesism.com" <charlesism.com-AT-gmail.com> wrote:

>> Exactly. It seems like this convention is a work-around for a
> language design deficiency. In the case of value types, there are
> indeed other solutions that could even allow the same name for
> functions to be used for both mutating and non-mutating. The key thing
> of importance is bringing that clarity to the call site.
>
> This makes a lot of sense. I'm glad we're considering design. There's
> rules to remember either way, but I'd prefer to use the same method
> name for both mutating and copying. Messing around with English
> grammar is a "naming problem" and costs a programmer more mental
> effort. Look no further than online debates over the best conjugation
> of this or that Protocol name.

OK, but please, take that discussion to a different thread, or even
consider delaying it.  As much as I wish it were otherwise (I originally
wrote that proposal before Swift 1 was released) something like the
InPlace proposal is so unlikely to be in scope for Swift 3 as to be
effectively irrelevant to the API Design Guidelines, which we are trying
to roll out immediately, and which can't be based on speculative feature
ideas.

-- 
-Dave