–∞
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 <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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
