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

Xiaodi Wu xiaodi.wu at gmail.com
Tue Oct 17 11:36:39 CDT 2017


On Tue, Oct 17, 2017 at 11:01 Thorsten Seitz <tseitz42 at icloud.com> wrote:

>
>
> Am 17.10.2017 um 14:46 schrieb Xiaodi Wu <xiaodi.wu at gmail.com>:
>
> On Tue, Oct 17, 2017 at 01:03 Thorsten Seitz <tseitz42 at icloud.com> wrote:
>
>>
>>
>> Am 17.10.2017 um 01:43 schrieb Xiaodi Wu via swift-evolution <
>> swift-evolution at swift.org>:
>>
>> On Mon, Oct 16, 2017 at 6:10 PM, Jonathan Hull <jhull at gbis.com> wrote:
>>
>>>
>>> On Oct 16, 2017, at 1:05 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>>
>>>
>>> On Mon, Oct 16, 2017 at 10:49 Jonathan Hull <jhull at gbis.com> wrote:
>>>
>>>>
>>>> On Oct 16, 2017, at 7:20 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>>>
>>>> To start with, the one you gave as an example at the beginning of this
>>>>> discussion: Two sets with identical elements which have different internal
>>>>> storage and thus give different orderings as sequences.  You yourself have
>>>>> argued that the confusion around this is enough of a problem that we need
>>>>> to make a source-breaking change (renaming it) to warn people that the
>>>>> results of the ‘elementsEqual’ algorithm are undefined for sets and
>>>>> dictionaries.
>>>>>
>>>>
>>>> No, I am arguing that the confusion about ‘elementsEqual’ is foremost a
>>>> problem with its name; the result of this operation is not at all undefined
>>>> for two sets but actually clearly defined: it returns true if two sets have
>>>> the same elements in the same iteration order, which is a publicly
>>>> observable behavior of sets (likewise dictionaries).
>>>>
>>>>
>>>> But that iteration order is undefined and could easily change due to
>>>> changes in the private/internal structure of sets/dictionaries.  Algorithms
>>>> that rely on that “publicly observable behavior” (i.e. leaking of
>>>> internals) will suddenly break.
>>>>
>>>
>>> And an algorithm in which such “sudden breakage” would occur is…?
>>>
>>>
>>> Here are a few off the top of my head:
>>>
>>> func hasPrefix(Sequence)->Bool
>>> func hasSuffix(Sequence)->Bool
>>> func containsSubsequence(Sequence)->Bool
>>>
>>> What do these methods mean with regards to Set’s “publicly observable
>>> behavior”?
>>>
>>
>> In what way do these algorithms break? They would continue to
>> determine--correctly--whether an instance of Set, when iterated, begins
>> with, ends with, or contains (respectively) a subsequence that matches the
>> argument.
>>
>>
>> Why do you not answe the question, what these methods *mean* for a Set?
>> Still waiting for a use case.
>>
>
> The method means exactly what I just said: the iteration order of one set
> matches the iteration order of another sequence. I’ve given you one use
> case and others have given more.
>
>
> Sorry, the use case you gave was just a clever trick instead of using
> `contains` and Float.isNaN. No one else has provided a use case for
> `elementsEqual` yet.
>

The purpose of protocols is to enable useful generic code. You cannot use
isNaN in generic code that operates on Collection (or even Set where
Element : Numeric) to prevent NaN from blowing up your sort. Comparing a
value to itself is not a “clever trick” but a common and ordinary method of
checking for NaN.


> -Thorsten
>
>
>
>
>> -Thorsten
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171017/89d3760d/attachment.html>


More information about the swift-evolution mailing list