> 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