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

[Xiaodi Wu]

On Sun, Oct 15, 2017 at 8:35 PM, Jonathan Hull <jhull at gbis.com> wrote:

>
> 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?
>

We can also document the iteration order as arbitrary (i.e., the status
quo).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171015/4c594877/attachment.html>