[swift-evolution] [SR-933] Rename flatten to flattened

[Антон Жилин]

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 <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
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160415/051f3884/attachment.html>