> On 19 Apr 2016, at 10:40, Brent Royal-Gordon via swift-evolution 
> <[email protected]> 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 
> <[email protected]> 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.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to