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

[Daniel Steinberg]

What I like about the inPlace suffix is

(1)  it makes it clear that a mutating variant is being used and
(2) the bulk of inPlace pushes us in the direction of non-mutating versions.


In early Swift I believe the names were sort and sorted and I could never remember which is which (yes, of course the signature makes that clear) but sort vs sortInPlace seems more clear to me as a consumer of an API.

That said, once a naming convention is settled - it will be easy enough to reason about as the guidelines will be clear.

Daniel 


> On Jan 22, 2016, at 6:17 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> on Fri Jan 22 2016, Joe Groff <swift-evolution at swift.org> wrote:
> 
>>      + When a mutating method is described by a verb, name its
>>      non-mutating counterpart according to the “ed/ing” rule,
>>      e.g. the non-mutating versions of x.sort() and x.append(y) are
>>      x.sorted() and x.appending(y).
>> 
>> This is a nice rule in theory, but English fights it with the full
>> fury of its irregularity. There are a lot of common operations whose
>> past tense shares a spelling with the infinitive—'split', 'cut',
>> 'read', and 'cast' immediately come to mind. How do you handle naming
>> non-mutating versions of these operations? Conjugating other irregular
>> verbs also imposes a barrier on developers whose first language is not
>> English.
> 
> Agreed.  There are also operations that are not naturally verbs.  That's
> why we still haven't changed unionInPlace in SetAlgebraType, for
> example.  The “InPlace” suffix convention is the best thing I've come up
> with for handling these scenarios.
> 
> -- 
> -Dave
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution