Thinking about it, `ed`/`ing` and even `form` prefix might not be that bad. It's more a matter of what should be "default" in a specific domain.
In imperative domain, mutating version usually feels as the most natural one. Think `sort`. Everyone knows that sort must modify the array (usually through a sequence of swaps) to be most efficient. (Heapsort is an exception there, I guess.) That's why it is mutating version should be the shorter one, and non-mutating should have a prefix or a suffix. In functional domain, non-mutating version usually feels as the most natural one. Think `filter`, `map`, `reduce`. This functions originated in functional languages. Functional languages usually have immutability by default. When we "map" these idioms to Swift, we should let non-mutating version be the "default" one. Of course, we can be strict with our own rules and inventive in terms of function names, but we just shouldn't. Think `union`, `intersection`. These terms originated from mathematics, where mutability just doesn't exist. Given such a domain area, it should be obvious that `union` on a set means non-mutating version, unless stated otherwise. So, I conclude that we should not enforce any guideline about naming mutating/non-mutating versions of methods. Correct me if this is a wrong conclusion. - Anton 2016-04-15 19:31 GMT+03:00 Erica Sadun <[email protected]>: > > On Apr 15, 2016, at 10:17 AM, Антон Жилин via swift-evolution < > [email protected]> wrote: > > I've already expressed these concerns, but nobody noticed, apparently. > Here is it: > > I think current -ed/-ing convention is ugly. It breaks syntactic > correctness, experience from other languages, mathematical notation and > functional idioms. > > `InPlace` suffix was so far more correct in these terms. We can make > anything a convention, but should we? > I liked the proposal about new naming conventions, but overlooked this > change. > > Many people will agree with me. This still can be reviewed until Swift 3. > If so, I will create a proposal to correct "the big three" in this. > > What do you think? > > > I would like to see a formal proposal along these lines. My other > suggestions are here > <http://ericasadun.com/2016/04/13/stop-the-madness-and-fix-the-swift-api-guidelines/> > . > > -- E > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
