[swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

Patrick Gili gili.patrick.r at gili-labs.com
Mon Apr 4 09:11:40 CDT 2016


Personally, I don't like any of the options. However, I mentioned this during the review of the API naming guidelines. Using the English language to construct function names that distinguish between functional and imperative forms of the operation places constraints on API designers that produce undesirable results. The operations on an algebraic set is merely one example. My preference is a symbol appended to the function name (e.g., the exclamation point in Ruby). However, it was pointed out at the time that introducing this syntax was out-of-scope for Swift 3. What does this mean? We'll revisit this later and have to endure the rigor of another API renaming exercise?

Without rehashing the utility of a symbol to distinguish between functional and imperative, what is my preference?

Pseudo-verbs? I don't know if this is any better.

A suffix, such as "InPlace", has some appeal for two reasons:

1) It is descriptive and doesn't obfuscate the meaning of the operation.

2) If at sometime later the community sees a practical need to introduce syntax to distinguish between functional and imperative forms of an operation, removing such a suffix and replacing it with the symbol will mitigate confusion of another renaming transition.

Cheers,
-Patrick

> On Apr 2, 2016, at 5:15 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
> 
>> For example, changing union() to formUnion() for the sake of aligning compliance to API name guidelines simply doesn't make sense to me.
> 
> Given the need for separate names for the functional and imperative forms of this operation, what sorts of names would be better? Pseudo-verbs like `unioning`? An `InPlace` suffix?
> 
> (Everyone else, please don't take this as an invitation to start the bikeshedding again. I'm trying to understand what *this reviewer* prefers.)
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 



More information about the swift-evolution mailing list