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

[Vladimir.S]

+1, almost totally agree.

IMO sort/map/filter/reduce/etc "belongs" to the functional word, as I can 
see Swift is moving to be more functional language, we like to use 
functional features like some.filter{}.map{}.reduce{}, we like such 
frameworks/libs like RxSwift/ReacriveCocoa, we are implementing 
Future<Result,Error> pattern, trying "Railway oriented programming" etc.
I think it is some kind of standard of naming for such functions and their 
behavior.

All this renaming is looking very strange for me, do we have more important 
things? IMO this is not normal, if we have "sort" as non-mutating in 
Swift2.0 (just like in other modern languages) but have "sort" as mutating 
in 3.0. Are we programming here or writing some poems etc? So we need all 
these "ing"/"ed"... Just can't understand and want some opinions from the 
community. Are you really support all this renaming?

But I extremely against "form" prefix : we will always read it as "from" : 
https://en.wikipedia.org/wiki/Typoglycemia


On 15.04.2016 23:36, Антон Жилин via swift-evolution wrote:
> 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
> <mailto:erica at ericasadun.com>>:
>
>
>>     On Apr 15, 2016, at 10:17 AM, Антон Жилин via swift-evolution
>>     <swift-evolution at swift.org <mailto: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
>
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>