[swift-evolution] [Draft] Rename Sequence.elementsEqual

Fri Oct 13 12:42:25 CDT 2017

Ok, sorry for that answer that was really too quick. It seems that i really
didn't answer the rational for the "elementsEqual" function in the first
place which seems to be related to comparing sequences of different types,
so just ignore my last comment.

I do however wants to reiterate my encouragement to core language
developers to not get frightened to make deep source breaking changes if it
helps developers stay away from undefined behaviors (such as preventing
people from using first() or elementsEquals() on sets).

On Fri, Oct 13, 2017 at 7:08 PM, Benjamin G via swift-evolution <
swift-evolution at swift.org> wrote:

> Hi, i'm not following this mailing for a long enough time, so i'm sorry if
> all this conversation already took place. It seems however pretty obvious
> to me what "ordered" and "unordered" means, and , knowing that collections
> have value semantics in swift, i would expect the regular "==" to take that
> difference into account, without having to resort to special functions..
> Same as i would expect a complex numbers struct to compare correctly the
> real and complex components, a vector compare correctly its dimension
> components, and a regular (unordered) set to work only in terms of unions,
> intersections and membership. Mostly because it seems to me that it's
> traditional mathematical definition of equality in those cases...
>
>
>
> On Fri, Oct 13, 2017 at 3:52 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
>> You’re welcome to bikeshed the entire API surface area of sequences and
>> collections, but you won’t be the first to explore this area. A number of
>> us looked into this area in the past few years and did not reach a
>> measurable improved result.
>>
>> Sequences can be ordered or unordered, single-pass or multi-pass, finite
>> or infinite, lazy or eager. Not all the combinations of these attributes
>> make sense, but many do. For each combination, a different subset of the
>> sequence algorithms are “useful.” As an example, “last” is not great for an
>> infinite sequence. It’s possibly also not what you want for a single-pass
>> sequence.
>>
>> Now, as to the problem discussed here. It’s an orthogonal problem to what
>> you are discussing because, whether or not you reorganize the protocols
>> entirely, there is still going to be confusion about how exactly
>> “elementsEqual” differs from “==“ even for an ordered sequence. The name is
>> clearly problematic in that respect. However, I would argue that the
>> behavior of the method isn’t “improper” and the behavior is not “badly
>> defined.”
>>
>>
>> On Fri, Oct 13, 2017 at 07:09 Benjamin G <benjamin.garrigues at gmail.com>
>> wrote:
>>
>>> +1 on both points. As for your solutions, i see 1/ as the best solution.
>>> Breaking source code that rely on badly defined, or improper behavior isn't
>>> "breaking".  You don't break something that's already half broken.
>>> As an app developer relying on swift on my day to day job and making a
>>> living of it, i want to emphasis this: I really don't mind if a language
>>> version change is making me look more carefully on some parts of my code
>>> that i probably had overlooked.
>>> Sure i may pester a bit when the code doesn't compile, but it sure is
>>> better than discovering the weird behavior of a badly defined protocol
>>> hierarchy in customer support.
>>>
>>>
>>> On Fri, Oct 13, 2017 at 6:57 AM, Kevin Nattinger via swift-evolution <
>>> 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.
>>>>
>>>> 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> 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
>>>> 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/6714ad7f/attachment.html>