On Sun, Oct 15, 2017 at 8:35 PM, Jonathan Hull <jh...@gbis.com> wrote:
> > On Oct 15, 2017, at 3:41 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > I’ll have to mull this over to see if I can come up with a coherent and >> (more) specific requirement for what makes an Iterable a Sequence, since >> clearly “documented” isn’t enough. Perhaps something along the lines that >> any two Sequences that compare equal must iterate the same. >> >> […] >> Apple documentation calls this one of the "order-dependent" methods. It >> is surely acceptable for a type that conforms to an order-dependent >> protocol to have methods that are order-dependent; they do, however, have >> to be clearly order-dependent to avoid confusion on unordered types. >> >> >> I’m not clear on what you’re trying to get across here. It seems you’re >> saying unordered types shouldn’t have order-dependent methods, which is >> exactly what I’ve been arguing. >> > > No, I'm saying, essentially, that there are no truly unordered types in > Swift; `Set` and `Dictionary` lead double lives modeling unordered > collections on the one hand and ordered collections on the other. The > order-dependent methods can continue to exist; they just need to be clearly > named so that users know when they're using an instance of `Set` in the > manner of an unordered collection and when they're using an instance of > `Set` in the manner of an ordered collection. > > > Is the order of elements returned from Set/Dictionary guaranteed not to > change based on implementation? For instance, the elements of a dictionary > may shift around as I add items, and they may be different in different > runs of a program. > > If we document/say that Set will always return elements in the order they > were added, then it may prevent us from using a more efficient > implementation of Sets in a future version of Swift. > > Just to check what we are saying. I am saying that we can’t really build > generic algorithms on something which is undefined (because we are leaking > implementation details, and depending on private implementation details > leads to problems). You are saying that the leaking of implementation > details is a feature, not a bug… and that we should just document them and > consider them fixed ABI? > We can also document the iteration order as arbitrary (i.e., the status quo).
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
