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

[Dave Abrahams]

on Wed Jun 29 2016, Matthew Johnson <swift-evolution at swift.org> wrote:

> Sent from my iPad
>
>> On Jun 29, 2016, at 1: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
>
> I didn't participate in this discussion but want to say that I am
> pleased with where it ended up.  IMO this looks much better than the
> earlier version as well as some of the alternative that were
> discussed.  I think brevity is important for the common functional
> operators and was previously concerned with the length of some of the
> names.
>
>> 
>> My current thoughts are that many of the `by:` labels are awkward and
>> not adding much.  Perhaps they all ought to be omitted.
>
> Some cases are more awkward than others.  The value added by a label
> is also greater in some cases than others.  Unfortunately I think
> these tend to coincide.
>
> That said, I do think the value of a label outweighs the awkwardness
> in cases like min and max.

? min and max are not under discussion here.

> One change you might consider is to use different labels for
> comparison and equivalence relations.  'by' feels more natural in the
> context of comparisons and brevity feels more important in the methods
> that use a comparator.  On the other hand, I think dropping the use of
> the word equivalent for 'starts' and 'elementsEqual' feels like a step
> back in clarity.  Maybe we use 'equivalentBy' in these cases.
>
> A suggestion for the future enhancements - rename elementsEqual to
> elementsEquivalent.  If we make that change the shorter 'by' label
> would feel much less awkward to me in this method.
>
> -Matthew
>
>> 
>> -- 
>> Dave
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
Dave