[swift-evolution] Take 2: Stdlib closure argument labels and parameter names

[Dave Abrahams]

Could we please take all the discussion of aliasing and the future
extensions bit of this PR into a different thread?  I'd like to keep
this discussion focused.

Thanks,
Dave

on Wed Jun 29 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote:

>> On Jun 29, 2016, at 10:13 AM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>>> On Jun 29, 2016, at 12:39 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>
>>> 
>>> I've updated my pull request with a much more conservative set of
>>> changes that preserves/restores label-free-ness for all “term of art”
>>> functional methods such as filter and reduce.
>>> 
>>> https://github.com/apple/swift/pull/2981
>>> 
>>> My current thoughts are that many of the `by:` labels are awkward and
>>> not adding much.  Perhaps they all ought to be omitted.
>> 
>> 
>> I'd be happy to see `by` labels go away, whether first or trailing. I'm not sure why Swift 3 wants 
>> to have so many extra labels when a very simple phrase is understandable on its own 
>> (e.g. max, min, sort, sorted).
>> 
>> Is it possible under the Swift umbrella to do the same for split since it has the rarely used
>> maxSplits, and omittingEmptySubsequences params? It would give you `split({$0 == " "})` 
>> and `split(atWhitespace)`.
>> 
>> Speaking of isAllWhitespace, would this be a prebuilt enumeration or is it a placeholder?
>> If the former, I have opinions (new lines, new lines and whitespace)
>> 
>> The managed buffer, are you "makingValueWith" instead of "makingHeaderWith" intentionally?
>> If so, no worries. If not, helpful ping.
>> 
>> Future Extensions:
>> 
>> * reduce(_:, combine:)  // way simpler
>> 
>> * "The argument against changing other names to be more consistent with API guidelines 
>> is weakened. "
>> 
>> I think Sean Heber's `@termOfArt(name)` is a great way to have both worlds, where 
>> `select(where:)` or `where()` is the Swifty name and `@termOfArt(filter)` offers
>> a substitutable alias for fp aficionados. 
>> This approach is not anything I've ever seen previously in a programming language but 
>> its something that jumps out as a way to satisfy two distinct audiences of users
>> that would have limited impact but a decided advantage.
>
> Aliasing methods is pretty common in Ruby.  The advantage is that you
> can select the alias that reads best at a specific call site.  The
> disadvantage is that everyone has to learn more than one name for the
> same thing.
>
> If we’re going to allow aliases I think it should be in support of
> clarity at specific call sites.  I think the hurdle for this is pretty
> high and I’m not sure we would find the benefits to outweigh the
> drawbacks, but it is a discussion we could have.  I would want to see
> concrete examples (which could be drawn from Ruby code).
>
> I don’t think we should do this just to support term-of-art aliases
> where we believe we have a different name that fits Swift better.
> This creates “dialects” which I believe is a stated anti-goal of
> Swift.
>
> It may turn out that existing terms of art provide enhanced clarity in
> some contexts and more Swifty names in others, in which case the alias
> may make sense.  But it if we add them it should be done on the
> grounds of clarity and be accompanied by guidelines regarding which
> name to choose.
>
> But my hunch is that this introduces more complexity than value.
>
>> 
>> That said, I don't like `mapping` and `flattened`. If they're going to be Swiftized, go with
>> names that aren't standing in the "term of art" rubble: transform, squeeze, whatever.
>> 
>> -- E
>> 
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
Dave