[swift-evolution] [Draft] Rename Sequence.elementsEqual

[Michael Ilseman]

> On Oct 17, 2017, at 1:36 PM, Benjamin G <benjamin.garrigues at gmail.com> wrote:
> 
> 
> 
> On Tue, Oct 17, 2017 at 10:25 PM, Michael Ilseman <milseman at apple.com <mailto:milseman at apple.com>> wrote:
> 
> 
>> On Oct 17, 2017, at 12:54 PM, Benjamin G <benjamin.garrigues at gmail.com <mailto:benjamin.garrigues at gmail.com>> wrote:
>> 
>> Thanks for the post, that's the first clear explanation i see on this thread for the concepts behind the design for Sequence.
>> 
>> I am a bit afraid that understanding all that is a bit above what to expect the average swift developer will guess when he sees functions like "prefix / first / elementEqual (or whatever it's called)" on the Set type.
>> There is, IMHO, a much higher chance he'll either : 
>> 1/ not understand anything, or 
>> 2/ think Sets are in fact secretely ordered sets, or start writing generic extensions above Sequence or Collection thinking those protocols are synonymous for orderer collections.
>> 
>> 1/ is pretty harmless, but 2/ seems like a source of bug.
>> 
>> My personal opinion after reading all this is that we should simply change the name
> 
> Exactly, and that’s what Xiaodi’s proposal does. Confronted with these complexities, his proposal reasons that a name change is the lessor or evils, as in the “Proposed solution” section.
> 
>> to sequentiallyEquals
> 
> Xiaodi floated “lexicographicallyEqual” which is accurate and a big improvement, and I’m liking it more and more. I floated “sequentiallyEquals”, which I’m liking less and less now. My current preference is for “elementsOrderedEqual” which I think is more descriptive but unwieldy. On the other hand, this is a far less common facility, and order matters, so maybe more verbose names are fine.
> 
> I'm sorry to bring more bikeshedding, but lexicographicallyEqual seems absolutely atrocious to me. Imagine all the steps required the user of a Set<Int> to understand why a lexicographicallyEqual function is suggested by the compiler ??
> 

My initial resistance is that lexicographical implies a comparability beyond equality. `lexicographicallyEquals`, then, had me (erroneously) wondering if the “lexicographically” part meant that the elements were presented in lexicographical order and then compared for equality. But, I was in error and this is a wrong interpretation of the term. “abc” is not lexicographically equal to “cba”, and it’s quite a mental leap to think that the order of elements would be presented differently. That’s not to say that others won't have the same misinterpretation and that’s why I’m hoping for a better name. But, if `lexicographicallyEquals` is what we settle on, that’s a huge improvement over `elementsEqual`.

> Since you seem to give the kind of answer i'm looking for, do you have any answer to a previous question i asked regarding the rational for conflating the iterator with the collection ?
> What i mean by that is : i think nobody would have cared if the syntax for Set was actually
> set1.iterator.elementEquals(set2.iterator)
> It's a bit more verbose, but the meaning is obvious.

To me that reads as meaning something more akin to set1.first == set2.first (whether nil or not). I think what you’re trying to demonstrate is an equality on an iterator that implies equality of iterated elements. But, there could be alternatives: if a Sequence has identity, then perhaps its iterator’s equality should enforce the identity. I may also be completing misunderstanding your question.

> I think a reason why people are confused is that the actual design conflates methods of the "iterator" on the collection type itself. An alternate design would have been to make collection Sequenceable rather than a sequence themselves. But i suppose you've thought about that already, so i'm just curious to know what made you choose the current solution instead.

No, I have not thought about it much. I’m a relatively new contributor (a few months) to the standard library, and am just now thinking about such things on an as-needed basis.

Personally, I care much more about what operations a data structure provides and how it does it than whatever protocol hierarchy it models. As far as what hierarchy should exist in the standard library, I care much more about pragmatism than purity as the hierarchy’s main benefit is to enable generic programming. I think George Box said it best: “All models are wrong, but some are useful”.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171017/6819c2d9/attachment.html>