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 >> <[email protected]> wrote: >> >> >>> on Wed Jun 29 2016, Matthew Johnson <[email protected]> wrote: >>> >>> Sent from my iPad >>> >>>> On Jun 29, 2016, at 1:39 AM, Dave Abrahams via swift-evolution >>>> <[email protected]> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
