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

[Patrick Smith]

On keeping map() as map() but keeping the -ed and -ing guideline for other APIs:
What defines prior art really? I’m fairly new to functional programming, but I imagine there is a plethora of other API designs that can be copied. In Swift, do they all take on the past-particle naming? 
Which consistency is more important, consistency with other popular libraries, or with the Swift naming guidelines recommending -ed and -ing?
What happens if new API designs are created from here on, are they considered to be prior art or not?
On why is there a need for -ed and -ing in the first place?:
Naming is called one of the hardest things in computer science for a reason. Swift is meant to make programming easier, so why doesn’t it make naming easier? Just keep things simple. Who cares if it’s not proper english (you will never achieve perfect sentences), as the APIs are far superior in readability and comprehension than either strcat() or stringByAppendingString() of old.
Objective-C was derided for its overly verbose naming, and now Swift wants to introduce a new quirk to again set it apart from other languages?

A divide in naming
In functional programming, the emphasis is on what is returned. filter returns an affected copy.
In object oriented programming, the emphasis is usually the target. NSMutableArray.removeLastObject() affects the receiver, and returns nothing.
They are both verbs in present tense, yet behave differently.
We have two worlds coming together in Swift, and somehow they have to meet up. So I see why the -ed and -ing rule was created, especially as it suits the Cocoa framework well with the newly shortened API naming. But still, I think it’s somewhat messy (and potentially unfortunate as Cocoa and its dependence on reference types will one day be the past).
The guidelines affect both functional and object-oriented approaches (the Swift standard library includes pieces of both), and they affect both value and reference types. They are broad rules for a varied landscape.
Patrick Smith
  On Apr 19 2016, at 7:56 pm, Haravikk via swift-evolution <swift-evolution at swift.org> wrote:  
      
On 19 Apr 2016, at 10:40, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
Totally agree with Brent, too. And I wouldn't rename flatten either.

A brief postscript on terms of art:

I wrote my first Python this week. I was very glad that `map` was named `map`. I just had to glance at the docs to see whether it was a function or a method and which argument came first. It took less time and involved less doubt than learning their closure syntax did.
Are you suggesting that if it had been named “mapped” or “mapping” that you would have been unable to find it? Any decent search engine and/or auto-complete should get you to the correct function just as quickly, again, I don’t think anyone is suggesting that these functions be radically renamed, just that their tense be altered to match the new naming convention, which doesn’t change the root word from which they are derived.
On 15 Apr 2016, at 12:49, Daniel Steinberg via swift-evolution <swift-evolution at swift.org> wrote:
I agree with this and add that the 2.2 naming is unambiguous. There’s no doubt what is meant by sortInPlace().

I’m normally in favour of more explicit meaning rather than less, but this where Swift’s type system and the @warn_unused_result attribute come into play to eliminate the need for it:
	myCollection.sorted()			// Warning, unused result	let sorted = myCollectioned.sort()	// Void return type
A more explicit term is only needed for functions where there is ambiguity in how they are used IMO, i.e- if a function is both mutating and has a return type. The fact that .sort() doesn’t return anything does a pretty good job of clarifying what it does.  


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160419/d7c72392/attachment.html>