> 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. >
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 > 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 <mailto: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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
