[swift-evolution] ed/ing, InPlace, Set/SetAlgebra naming resolution

[Stephen Canon]

> On Feb 11, 2016, at 6:20 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Feb 11, 2016, at 4:17 PM, Dave Abrahams <dabrahams at apple.com <mailto:dabrahams at apple.com>> wrote:
>> 
>> For the record, I do not feel at all confident anything like this will
>> end up in swift.  This feature was proposed back in 2013, before Swift
>> was released, eventually accepted then not implemented because we were
>> out of time, then revised, then re-accepted and implemented, then ripped
>> out of the compiler because of various concerns about what it does to
>> the shape of the language (e.g. is this just a second version of
>> “mutating?”  What about classes?).  Based on history, I don't think it's
>> a sure bet, and I personally may be out of energy and time to fight for
>> it.  But we'll have to see...
>> 
> 
> Using foo and fooInPlace is obvious, understandable, and easy. As a suffix, it perfectly communicates the difference between a mutating and non-mutating version, and doesn't involve anything on the level of gerunds, past participles, pluperfects, prozac, or anything like that.

Seconded.  Attempting to convey a precisely-defined abstract property (mutating) via the irregular grammatical conjugation rules of the English language is madness.  There should be a single unambiguous sigil for mutating methods.  “InPlace" is verbose, but totally unambiguous and usable.

My own preference would be to adopt the “=“-prefixed mutating method names from the in place proposal Dave linked to.  If that’s not going to happen for whatever reason, “InPlace” is far less cumbersome than “ed/ing”.  “unioning” is horrifying.

– Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160211/bf1ad99b/attachment.html>