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

[Xiaodi Wu]

On Sat, Oct 14, 2017 at 10:55 PM, Jonathan Hull <jhull at gbis.com> wrote:

>
> On Oct 14, 2017, at 7:55 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> > Ordered, yes, but it’s only admittedly poor wording that suggests
> multi-pass, and I don’t think anything there suggests finite.
>
> If a Sequence is "guaranteed to iterate the same every time," then surely
> it must be multi-pass; what's the alternative?
>
>
> Single-pass, but where two dictionaries/sets with the same elements would
> be guaranteed to output the same ordering.
>

I'm not sure I understand. A single-pass sequence is one where iteration
can happen only once because it is destructive. By definition, then, it is
not guaranteed to "iterate the same" a second time. Neither sets nor
dictionaries are single-pass sequences. Kevin says that his definition of a
"Sequence" is something "guaranteed to iterate the same every time," which
requires them to be multi-pass, does it not?


> That ordering can be arbitrary, but it shouldn’t leak internal
> representation such that the method used to create identical things affects
> the outcome of generic methods because of differences in internal
> representation.
>
>
>  It would be better to say that the iteration order is well-defined. That
> will almost always mean documented, and usually predictable though
> obviously e.g. RNGs and iterating in random order will not be predictable
> by design.
>
>>
>> That's actually more semantically constrained than what Swift calls a
>> `Collection` (which requires conforming types to be multi-pass and(?)
>> finite). By contrast, Swift's `SpongeBob` protocol explicitly permits
>> conforming single-pass, infinite, and/or unordered types.
>>
>>
>> I think you’re talking about Sequence here, I’ve lost track of your
>> nonsense by now. Yes, the current Swift protocol named Sequence allows
>> unordered types. You seem to keep asserting that but not actually
>> addressing my argument, which is *that allowing Sequences to be
>> unordered with the current API is undesired and actively harmful, and
>> should* *therefore** be changed*.
>>
>
> What is harmful about it?
>
>
> After thinking about it, I think the harmful bit is that unordered
> sequences are leaking internal representation (In your example, this is
> causing people to be surprised when two sets with identical elements are
> generating different sequences/orderings based on how they were created).
> You are correct when you say that this problem is even true for for-in.
>

I would not say it is a problem. Rather, by definition, iteration involves
retrieving one element after another; if you're allowed to do that with
Set, then the elements of a Set are observably ordered in some way. Since
it's not an OrderedSet--i.e., order doesn't matter--then the only sensible
conclusion is that the order of elements obtained in a for...in loop must
be arbitrary. If you think this is harmful, then you must believe that one
should be prohibited from iterating over an instance of Set. Otherwise, Set
is inescapably a Sequence by the Swift definition of Sequence. All
extension methods on Sequence like drop(while:) are really just
conveniences for common things that you can do with iterated access; to my
mind, they're essentially just alternative ways of spelling various
for...in loops.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171014/6e040b64/attachment.html>