> On Oct 13, 2017, at 10:12 AM, Kevin Nattinger <[email protected]> wrote:
>
>>
>> On Oct 13, 2017, at 10:01 AM, Michael Ilseman <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>>
>>> On Oct 12, 2017, at 9:57 PM, Kevin Nattinger via swift-evolution
>>> <[email protected] <mailto:[email protected]>> 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
>> <https://en.wikipedia.org/wiki/Lexicographical_order>
> I see, apologies for the mistake.
No worries, I think my comment came across too blunt. Sorry about that. I was
trying to defend the word “lexicographical” which I think is a very useful word
to have at our disposal :-)
> 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.
>
Right, and thus cuts to the heart of what Xiaodi raised in the proposal’s third
potential solution.
Quoted from the proposal:
> A third solution is to dramatically overhaul the protocol hierarchy for Swift
> sequences and collections so that unordered collections no longer have
> members such as first and elementsEqual(_:). However, this would be a
> colossal and source-breaking undertaking, and it is unlikely to be
> satisfactory in addressing all the axes of differences among sequence and
> collection types:
>
> Finite versus infinite
> Single-pass versus multi-pass
> Ordered versus unordered
> Lazy versus eager
> Forward/bidirectional/random-access
Is seems like you’re arguing we should attack the “Ordered versus unordered”
dichotomy prior to any name change. Is that correct?
>>
>>> 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
>>>> <[email protected] <mailto:[email protected]>> 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
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
