[swift-evolution] [SR-933] Rename flatten to flattened
antonyzhilin at gmail.com
Fri Apr 15 15:36:13 CDT 2016
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
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
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.
2016-04-15 19:31 GMT+03:00 Erica Sadun <erica at ericasadun.com>:
> On Apr 15, 2016, at 10:17 AM, Антон Жилин via swift-evolution <
> swift-evolution at swift.org> 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
> 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
> -- E
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution