On Tue, Oct 17, 2017 at 11:01 Thorsten Seitz <tseit...@icloud.com> wrote:
> > > Am 17.10.2017 um 14:46 schrieb Xiaodi Wu <xiaodi...@gmail.com>: > > On Tue, Oct 17, 2017 at 01:03 Thorsten Seitz <tseit...@icloud.com> wrote: > >> >> >> Am 17.10.2017 um 01:43 schrieb Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org>: >> >> On Mon, Oct 16, 2017 at 6:10 PM, Jonathan Hull <jh...@gbis.com> wrote: >> >>> >>> On Oct 16, 2017, at 1:05 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: >>> >>> >>> On Mon, Oct 16, 2017 at 10:49 Jonathan Hull <jh...@gbis.com> wrote: >>> >>>> >>>> On Oct 16, 2017, at 7:20 AM, Xiaodi Wu <xiaodi...@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@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
