On Sat, Oct 14, 2017 at 11:48 PM, Jonathan Hull <jh...@gbis.com> wrote:
> > 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> wrote: > >> >> On Oct 14, 2017, at 7:55 PM, Xiaodi Wu via swift-evolution < >> 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). > Right, but I'm trying to figure out why Kevin wants a Sequence to "iterate the same every time" and in what way that's not simply a Collection. > > >> 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. > Well, that's a totally different direction, then; you're arguing that `Set` and `Dictionary` should not conform to `Sequence` altogether. That's fine (it's also a direction that some of us explored off-list a while ago), but at this point in Swift's evolution, realistically, it's not within the realm of possible changes. > 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. > The underlying source of the confusion is clear; I'm trying to encourage us *not* to talk about it here, though, as it's not a tractable problem for Swift 5.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution