[swift-evolution] [Draft] Rename Sequence.elementsEqual
Max Moiseev
moiseev at apple.com
Fri Oct 13 17:42:25 CDT 2017
> On Oct 13, 2017, at 1:34 PM, Howard Lovatt via swift-evolution <swift-evolution at swift.org> wrote:
>
> I am very glad that this issue is getting some air time since the ‘loose’ definitions in `Sequence` are a pain.
>
> I am in the camp that thinks the best solution is to split `Sequence`. I would propose splitting into `Iterable` and `Sequence`, `Sequence` is ordered. `Set` and `Dictionary` would implement `Iterable` and a `for` loop would work with `Iterable`. That way only already broken code is affected.
>
> At present we have `Set` and `Dictionary` that are problems in the standard library and this justifies the split.
>
> If other collection types are added to the standard library that require further sub-division of sequence then split sequence further at that time.
Unfortunately there already ‘other’ collections in the standard library, as Xiaodi points out, lazy collections, eager collections, finite collections, infinite collections…
Splitting Sequence is almost trivial, handling the consequences of this split downstream (in more refined protocols) is a problem.
Max
>
> -- Howard.
>
> On 14 Oct 2017, at 6:41 am, Jonathan Hull via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>
>> I would also expect lexicographicallyEquals to sort the elements (or otherwise create/reference a total ordering) before checking for equality. I would be more surprised by the behavior of a function named this than elementsEqual.
>>
>> Given the name, I would expect elementsEqual to return true if two sequences have the same elements, regardless of ordering (this would be a valuable function IMHO). I would expect lexicographicallyEquals to compare the elements in some lexicographical order defined for the type which overrides the internal ordering of the sequence.
>>
>> Kevin is right… the real answer is that the actual intended function really shouldn’t exist on unordered sequences.
>>
>> Thanks,
>> Jon
>>
>>> On Oct 13, 2017, at 10:12 AM, Kevin Nattinger via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>
>>>>
>>>> On Oct 13, 2017, at 10:01 AM, Michael Ilseman <milseman at apple.com <mailto:milseman at apple.com>> wrote:
>>>>
>>>>
>>>>
>>>>> On Oct 12, 2017, at 9:57 PM, Kevin Nattinger via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>
>>>>> –∞
>>>>>
>>>>> 1. I strongly object to the proposed name. It doesn't make it more clear to me what the method does, and is misleading at best. Among other issues, "lexicographical" is defined as alphabet order, and (1) this method applies to objects that are not Strings, and (2) this method's behavior isn't any more well-defined for Strings, so that name is even more of a lie than the original.
>>>>>
>>>>
>>>> FWIW, in the context of String, "lexicographical ordering” does not imply human-written-language-alphabetical order at all, as there’s no universal alphabetical ordering for human language. I.e., such a concrete notion for Strings does not exist, not even theoretically. “Lexicographical” derives its meaning from the mathematical usage[1] which uses that term as well as “alphabet” without being restricted to human-written-language, in which it means some total ordering over a finite set.
>>>>
>>>> [1] https://en.wikipedia.org/wiki/Lexicographical_order <https://en.wikipedia.org/wiki/Lexicographical_order>
>>> I see, apologies for the mistake.
>>> Regardless of the specific type of ordering, lexicographicallyEquals says to me that the objects should be sorted into lexicographical order and compared. Precisely the opposite of the proposal.
>>>
>>>>
>>>>> 2. This is really just a symptom of a bigger problem. The fact that two Sets can compare equal and yet return different results for that method (among too many others) is logically inconsistent and points to a much deeper issue with Set and Sequence. It is probably about 3 releases too late to get this straightened out properly, but I'll outline the real issue in case someone has an idea for fixing it.
>>>>>
>>>>> The root of the problem is that Set conforms to Sequence, but Sequence doesn't require a well-defined order. Since Set doesn't have a well-defined order, a significant portion of its interface is unspecified. The methods are implemented because they have to be, but they doesn't have well-defined or necessarily consistent results.
>>>>>
>>>>> A sequence is, by definition, ordered. That is reflected in the fact that over half the methods in the main Sequence definition* make no sense and are not well-defined unless there is a well-defined order to the sequence itself. What does it even mean to `dropFirst()` in a Set? The fact that two objects that compare equal can give different results for a 100% deterministic function is illogical, nonsensical, and dangerous.
>>>>>
>>>>> * 7/12 by my count, ignoring `_*` funcs but including the `var`
>>>>>
>>>>> The current contents of Sequence can be cleanly divided into two groups; those that return SubSequence imply a specific ordering, and the rest do not.
>>>>>
>>>>> I think those should be/should have been two separate protocols:
>>>>>
>>>>> public protocol Iterable {
>>>>> associatedtype Iterator: IteratorProtocol
>>>>> func map<T>(...) -> [T] // Iterable where .Iterator.Element == T
>>>>> func filter(...) -> [Iterator.Element] // Iterable where .Iterator.Element == Self.Iterator.Element
>>>>> func forEach(...)
>>>>> func makeIterator() -> Iterator
>>>>> var underestimatedCount: Int { get }
>>>>> }
>>>>>
>>>>> public protocol Sequence: Iterable { // Maybe OrderedSequence just to make the well-defined-order requirement explicit
>>>>> associatedtype SubSequence
>>>>> func dropFirst(...) -> SubSequence // Sequence where .Iterator.Element == Self.Iterator.Element
>>>>> func dropLast(...) -> SubSequence // " "
>>>>> func drop(while...) -> SubSequence // " "
>>>>> func prefix(...) -> SubSequence // " "
>>>>> func prefix(while...) -> SubSequence // " "
>>>>> func suffix(...) -> SubSequence // " "
>>>>> func split(...where...) -> [SubSequence] // Iterable where .Iterator.Element == (Sequence where .Iterator.Element == Self.Iterator.Element)
>>>>> }
>>>>>
>>>>> (The comments, of course, would be more sensible types once the ideas can actually be expressed in Swift)
>>>>>
>>>>> Then unordered collections (Set and Dictionary) would just conform to Iterable and not Sequence, so ALL the methods on those classes would make logical sense and have well-defined behavior; no change would be needed for ordered collections.
>>>>>
>>>>> Now, the practical matter. If this were Swift 1->2 or 2->3, I doubt there would be a significant issue with actually making this change. Unfortunately, we're well beyond that and making a change this deep is an enormous deal. So I see two ways forward.
>>>>>
>>>>> 1. We could go ahead and make this separation. Although it's a potentially large breaking change, I would argue that because the methods are ill-defined anyway, the breakage is justified and a net benefit.
>>>>>
>>>>> 2. We could try and think of a way to make the distinction between ordered and unordered "sequences" in a less-breaking manner. Unfortunately, I don't have a good suggestion for this, but if anyone has ideas, I'm all ears. Or eyes, as the case may be.
>>>>>
>>>>>
>>>>>> On Oct 12, 2017, at 4:24 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>>
>>>>>> Rename Sequence.elementsEqual
>>>>>>
>>>>>> Proposal: SE-NNNN <https://gist.github.com/xwu/NNNN-rename-elements-equal.md>
>>>>>> Authors: Xiaodi Wu <https://github.com/xwu>
>>>>>> Review Manager: TBD
>>>>>> Status: Awaiting review
>>>>>> <https://gist.github.com/xwu/1f0ef4e18a7f321f22ca65a2f56772f6#introduction>Introduction
>>>>>>
>>>>>> The current behavior of Sequence.elementsEqual is potentially confusing to users given its name. Having surveyed the alternative solutions to this problem, it is proposed that the method be renamed to Sequence.lexicographicallyEquals.
>>>>>>
>>>>>> [...]
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171013/286e8ed0/attachment.html>
More information about the swift-evolution
mailing list