> On Oct 14, 2017, at 9:21 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Sat, Oct 14, 2017 at 10:55 PM, Jonathan Hull <jh...@gbis.com > <mailto:jh...@gbis.com>> wrote: > >> On Oct 14, 2017, at 7:55 PM, Xiaodi Wu via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@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?
But if I am comparing two single-pass things, the order can still be defined when they compare that one time. Single-pass doesn’t mean that the order is undefined. On the contrary, as you point out, it has a “first” thing, and then a thing after that, and so on. Regardless, most of the objects we are talking about here are multi-pass collections (e.g. sets). > > 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. I think an argument could be made that you shouldn’t be able to iterate over a set without first defining an ordering on it (even if that ordering is somewhat arbitrary). Maybe we have something like a “Sequenc(e)able” protocol which defines things which can be turned into a sequence when combined with some sort of ordering. One possible ordering could be the internal representation (At least in that case we are calling it out specifically). If I had to say “setA.arbitraryOrder.elementsEqual(setB.arbitraryOrder)” I would definitely be less surprised when it returns false even though setA == setB. If that is unergonomic, we could define an arbitrary but consistent ordering over all Swift types that can be used to create a predictable sequence order for unordered types. That is necessarily slower, but much safer… and people concerned with speed could use something like ‘arbitraryOrder’ above to regain full speed. I am not arguing that that is necessarily the right approach, just that we need more thought/discussion around what is actually causing the confusion here: The fact that we are assuming an ordering on something where the ordering is undefined. Thanks, Jon
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
