I agree that the proposed name is a poor choice. If we just focus on the naming
part, there is precedent in other languages for the name “sequenceEqual”. I
think that name makes it a bit clearer that the result is whether the sequences
match pair wise rather than whether they have the same elements irrespective of
order. I don’t think it entirely solves the problem, but I like it a lot better
than the proposed name.
--
Adam Kemp
> On Oct 12, 2017, at 9:57 PM, Kevin Nattinger via swift-evolution
> <swift-evolution@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.
>
> 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@swift.org> wrote:
>>
>> Rename Sequence.elementsEqual
>>
>> Proposal: SE-NNNN
>> Authors: Xiaodi Wu
>> Review Manager: TBD
>> Status: Awaiting review
>> 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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
