[swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

[Dave Abrahams]

on Mon Jun 20 2016, Brent Royal-Gordon <brent-AT-architechies.com> wrote:

>>> And as I said, if we feel `filter` is unsalvageable, the alternate
>>> Smalltalk-lineage `select` is clearer.
>> 
>> Than “where?”
>
> No, than "filter". "filter" is the most common name, but "select" is
> also fairly popular, and doesn't have the same ambiguity issues as
> "filter". 

True.

> "where" is slightly clearer than "filter", but it finds little
> precedent in other languages (the only other use I'm aware of is in
> SQL and LINQ, which are declarative), ignores the normal grammar rules
> for a method ("where" is an adverb, not a noun or verb),

There's no rule that says the base name should be a noun or verb.  The
rule says that *usage* should be a verb *phrase* or noun *phrase.*

> and is already a language keyword which has been overloaded with
> several slightly different semantics, including list filtering in the
> `for` loop.
>
>>>> – There's very significant brevity issues here, e.g. hyperbolicArcTangent() vs atanh().
>>> 
>>> Sure, but `mappingAndFlattening(to:)` would have brevity issues as
>>> well. (You didn't think the API Guidelines merely meant "add -ed or
>>> -ing to everything", did you?)
>> 
>> That would, IMO, be:
>> 
>>  x.flatMapping(fourCopies)
>
> Why? 

Because one (flat)maps a function over a sequence.  The function is the direct
object.

> If we're leaving the terms of art behind, we probably ought to
> consider that the base name `flatMap` is rather opaque to new users;
> I've seen people in my NSCoder group struggle with it. For that
> matter, `map` and `reduce` aren't the best names either.
>
> I can understand wanting to keep terms of art even if they're a little
> opaque. I can understand wanting to invent new, clear terms. I cannot
> understand wanting to make minor cosmetic changes to the terms of art
> while still keeping the parts that make them opaque. You lose many of
> the benefits of a term of art *and* most of the benefits of a new
> term.

I agree.  However, we really need to discuss
http://article.gmane.org/gmane.comp.lang.swift.evolution/21046 before we
go any further down this road.

-- 
Dave