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. -- Howard. > On 14 Oct 2017, at 6:41 am, Jonathan Hull via swift-evolution > <swift-evolution@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@swift.org> wrote: >>> >>> >>>> On Oct 13, 2017, at 10:01 AM, Michael Ilseman <milse...@apple.com> wrote: >>>> >>>> >>>> >>>> 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 >> >> 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@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 > > _______________________________________________ > 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
