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

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

After hitting Send button, I remembered that "Enhanced floating-point
protocols" proposal uses `add`, `subtract`, `multiply` and `divide` names
for mutating versions.
They should be non-mutating by default, as well as other purely
mathematical terms. I don't know how it can be unobvious.

- Anton

2016-04-15 23:36 GMT+03:00 Антон Жилин <antonyzhilin at gmail.com>:

> 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/2fcb5ba4/attachment.html>