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

Jonathan Hull jhull at gbis.com
Sun Oct 15 20:35:45 CDT 2017


> On Oct 15, 2017, at 3:41 PM, Xiaodi Wu via swift-evolution <swift-evolution at 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?

Thanks,
Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171015/7e1d07e3/attachment.html>


More information about the swift-evolution mailing list