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

[Dave Abrahams]

on Fri Jul 01 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote:

> Sent from my iPad
>
>> On Jul 1, 2016, at 7:03 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>>> 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.
>
> Really?  It looks like they're in your table:
>
> smallest = shapes.min(
>   isOrderedBefore: haveIncreasingSize)	
> smallest = shapes.min(
>   by: haveIncreasingSize)
>
> largest = shapes.max(
>   isOrderedBefore: haveIncreasingSize)	
> largest = shapes.max(
>   by: haveIncreasingSize)

Oops, sorry, you're right.

>>> 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.

I have a hard time justifying that to myself.  Taking the examples from
the PR,

  if expected.elementsEqual(actual, by: haveSameValue) { ... }

  if names.starts(with: myFamily, by: areSameExceptForCase) { ... }

vs.

  if expected.elementsEqual(actual, equivalentBy: haveSameValue) { ... }

  if names.starts(with: myFamily, equivalentBy: areSameExceptForCase) { ... }

If I was going to add words to “by,” I'd go with “determinedBy:”

  if expected.elementsEqual(actual, determinedBy: haveSameValue) { ... }

  if names.starts(with: myFamily, determinedBy: areSameExceptForCase) { ... }

but then I think that applies equally well to min and max, which are
doing ordering comparison instead of equality.

>>> 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.

Then the basename connection between the predicated and non-predicated
elementsEqual is broken.  Not out of the question, but doesn't seem
worth it to me.

-- 
Dave