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

[Jessy Catterwaul]

Text is not enough to represent whether function are adjectives or verbs. By distinguishing between adjectives (nonmutating) and verbs (mutating) functions, with metadata, we will also be able to settle when to enforce self. 

When a function is a mutating verb (i.e. when self. really means “self, "), self. reads redundantly.
When a function is an adjective (i.e. when self. means “me, "), it doesn’t read well if self. is not used.

sort(…)
self.sorted(…)

append(…)
self.appended(with …)

split(using: …)
self.split(by: …)

cut(…)
self.cut(by: …)

Sometimes, “self.” means “I”, but I don’t believe those cases are relevant to this thread.


> On Jan 22, 2016, at 4:53 PM, Joe Groff via swift-evolution <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.
> 
> -Joe
> _______________________________________________
> 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/20160122/9f01e463/attachment.html>