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

[Xiaodi Wu via swift-evolution]

On Fri, Oct 13, 2017 at 11:58 PM, Adam Kemp  wrote:

> > That the proposed name is obtuse is intentional--as Nate has
> surmised--as a way to prompt the unfamiliar user to look up the
> documentation.
>
> This is a strange philosophy for naming things. I see what you’re saying,
> but it feels very wrong to deliberately name something such that people
> will not understand it without documentation. I feel like we can do better
> than that.


That's not exactly the philosophy. The overarching desiderata are:

1. This method must be named in such a way that clearly conveys that it is
not plausibly a spelling for `==`. To my best estimation, users who
unintentionally use `elementsEqual` instead of `==` do so because they see
the former listed when they read the documentation but don't see the latter
(as operators suffer from various discoverability issues), and then they
think, "Swift designers must have decided to use this spelling as the
equivalent of `==` for arrays." By contrast, no one sees
`lexicographicallyPrecedes` and thinks, "Swift designers must have decided
to use this spelling as the equivalent of `<` for arrays!"

2. If a user is familiar with what a lexicographical comparison is, then
they should be able to (correctly) identify this method as of a kind
without going to the documentation. If a user is unfamiliar with what a
lexicographical comparison is, then they should not be misled by the method
name to think that it is something other than what it is; they need to read
the documentation and we do a good thing by alerting them to that need by a
carefully thought-out name--we are not thereby *creating* additional
demands to consult the documentation.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adam Kemp via swift-evolution]

> That the proposed name is obtuse is intentional--as Nate has surmised--as a 
> way to prompt the unfamiliar user to look up the documentation.

This is a strange philosophy for naming things. I see what you’re saying, but 
it feels very wrong to deliberately name something such that people will not 
understand it without documentation. I feel like we can do better than that. 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Fri, Oct 13, 2017 at 8:45 PM, Brent Royal-Gordon 
wrote:

> > On Oct 12, 2017, at 9:57 PM, Kevin Nattinger via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > That is reflected in the fact that over half the methods in the main
> Sequence definition* make no sense and are not well-defined unless there is
> a well-defined order to the sequence itself. What does it even mean to
> `dropFirst()` in a Set?
>
> It means to skip the first element the set would normally have given you.
> Which element this will be may be arbitrary, but this is still not useless:
>
> set.dropFirst().reduce(set.first!, …)
>
> Even elementsEqual(_:) does tell you something potentially valuable:
> Whether two instances will end up giving the same result when processed by
> an ordering-sensitive algorithm.
>
> We should change the name to something like orderEquals(_:), and maybe
> change the lexicographicallyPrecedes(_:) method to something analogous like
> orderPrecedes(_:), and then be done with it.
>

Fair enough suggestion as well.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Fri, Oct 13, 2017 at 4:52 PM, Christopher Whidden <
christopher.whid...@gmail.com> wrote:

> Using the term “lexicographically” implies to me that the Element type
> must conform to Comparable, as would be required for a total order.  The
> Sequence method you mention, lexicographicallyPrecedes(_:), does have this
> constraint, whereas the method in question for elementsEqual(_:) /
> lexicographicallyEquals(_:) only has the constraint that the Element is
> Equatable.  As an example, an array of simple enums has no default
> lexicographical ordering but is still able to use this method because enums
> (without associated values) are Equatable by default:
>
> *enum* Foo {
> *case* bar
> *case* baz
> }
>
> *let* f1 = [Foo.bar, Foo.baz]
> *let* f2 = [Foo.baz, Foo.bar]
>
> f1.elementsEqual(f2) //false
> f1.elementsEqual(f2.reversed()) //true
>
> I also share Jonathan’s concerns that some programmers may misinterpret
> [lexicographically][Equals] to mean [sorted in lexicographical
> order][compare sequence equality], which is not what the method in question
> does.
>
> Xiaodi, I think you are right that Sequence.sequentiallyEquals is to close
> to "==" to use, but I think we have to find something better here.
>
> I’ll recommend that we use the name *Sequence.iterativelyEquals(_:)* since
> this describes the body of the method concisely.  A rough abbreviation of
> this algorithm is:
>
> 1. Iterate over elements in two sequences
> a. Compare elements for equality
>
> “iterativelyEquals" concisely describes this.
>

That's an intriguing alternative. The key quality to be communicated,
practically speaking, is that if two instances `x` and `y` compare `true`
with `elementsEqual`, then `for i in x { ... }` and `for i in y { ... }`
should be substitutable (if the elements of `x` and `y` are not consumed on
the first iteration), because the semantics of `Equatable` demand that
"equivalence means substitutability." This would be captured by something
like the name you suggest, or to be even more explicit:

```
x.substitutesForThePurposesOfIteratedAccess(for: y)
```

This is intentionally unwieldy to attract others to try to do better :) But
I think it captures the meaning we are going for here.


> On Oct 12, 2017, at 6:24 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Rename Sequence.elementsEqual
>
>- Proposal: SE-
>
>- Authors: Xiaodi Wu 
>- Review Manager: TBD
>- Status: *Awaiting review*
>
> 
> Introduction
>
> The current behavior of Sequence.elementsEqual is potentially confusing
> to users given its name. Having surveyed the alternative solutions to this
> problem, it is proposed that the method be renamed to Sequence.
> lexicographicallyEquals.
> 
> Motivation
>
> As outlined by Ole Begemann
> , use of
> Sequence.elementsEqual(_:) can lead to surprising results if the
> sequences compared are unordered:
>
> var set1: Set = Set(1...5)var set2: Set = Set((1...5).reversed())
>
> set1 == set2 // trueset1.elementsEqual(set2) // false
>
> This result does reflect the *intended and documented* behavior of the
> elementsEqual(_:) method, which performs a *lexicographical* elementwise
> comparison. That is, the method first compares set1.first to set2.first,
> then (if the two elements compare equal) compares the next element stored
> internally in set1 to the next element stored internally in set2, and so
> on.
>
> In almost all circumstances where a set is compared to another set, or a
> dictionary is compared to another dictionary, users should use == instead
> of elementsEqual(_:).
>
> Proposed
> solution
>
> The proposed solution is the result of an iterative process of reasoning,
> presented here:
>
> The first and most obvious solution is to remove the elementsEqual(_:)
> method altogether in favor of ==. This prevents its misuse. However,
> because elementsEqual(_:) is a generic method on Sequence, we can use it
> to compare an instance of UnsafeBufferPointer to an instance of [Int].
> This is a useful and non-redundant feature which would be eliminated if the
> method is removed altogether.
>
> A second solution  is to
> create overloads that forbid the use of the elementsEqual(_:) method
> specifically in non-generic code. This would prevent misuse in non-generic
> code; however, it would also forbid legitimate mixed-type comparisons in
> non-generic code while failing to prevent misuse in generic code. The
> solution also creates a difference in the behavior of generic and
> non-generic code calling the same method, which is potentially 

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

[Xiaodi Wu via swift-evolution]

On Fri, Oct 13, 2017 at 3:06 PM, Jonathan Hull  wrote:

> It has been a while, but I believe a lexicographical ordering is basically
> a mapping from a set to the natural numbers (which should, in effect,
> provide a total ordering).  The mapping itself can be arbitrary, but the
> same set of things should never map to two different sequences (which just
> happens to be the example given).
>
> This tells me that “lexicographicallyPrecedes” is actually misnamed unless
> it refers to something which has a defined totally ordering.
>

By defining lexicographical equivalence and precedence, a total order is
defined for the set of all sequences that have the same element type. That
is, defining lexicographical equivalence and precedence for sequences of
Foos imposes a total ordering over the set of all sequences of Foos. Notice
that `lexicographicallyPrecedes` refers to the singular sequence being
ordered with respect to other sequences, not to the elements of the
sequence.

If we are looking to rename elementsEqual (which I would expect to check if
> the same elements are present regardless of ordering), I would recommend
> *elementOrderingEqual* or something like that that references that the
> answer will be affected by the internal representation/ordering of the
> sequence.
>
> Thanks,
> Jon
>
> On Oct 13, 2017, at 11:10 AM, Jarod Long via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> The name that feels natural to me would be `sequentiallyEquals`. I don't
> dispute that the term "lexicographical" is used correctly here, although at
> least for me personally, it's not a word that I encounter frequently enough
> to understand what this method would do without reading the documentation.
> Like Kevin, if I were to guess what the method did without checking, I
> would probably think that it compared lexicographically-sorted versions of
> the collections.
>
> But the consistency with `lexicographicallyPrecedes` is a pretty strong
> argument, although `sequentiallyPrecedes` would also feel more natural to
> me there, and my suspicion about the mentioned lack of evidence that the
> method has been a pitfall for users is that it's not actually used often
> enough out in the wild to have heard much about it. That's just a guess
> though. This proposal is the first time I've learned of its existence.
>
> In any case, my ideal version of this proposal would use
> `sequentiallyEquals` and also rename `lexicographicallyPrecedes` to
> `sequentiallyPrecedes`, but I still like the proposal overall as-is. Thanks
> for bringing it forward!
>
> Jarod
>
> On Oct 12, 2017, 16:24 -0700, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org>, wrote:
>
> Rename Sequence.elementsEqual
>
>- Proposal: SE-
>
>- Authors: Xiaodi Wu 
>- Review Manager: TBD
>- Status: *Awaiting review*
>
> 
> Introduction
>
> The current behavior of Sequence.elementsEqual is potentially confusing
> to users given its name. Having surveyed the alternative solutions to this
> problem, it is proposed that the method be renamed to Sequence.
> lexicographicallyEquals.
> 
> Motivation
>
> As outlined by Ole Begemann
> , use of
> Sequence.elementsEqual(_:) can lead to surprising results if the
> sequences compared are unordered:
>
> var set1: Set = Set(1...5)var set2: Set = Set((1...5).reversed())
>
> set1 == set2 // trueset1.elementsEqual(set2) // false
>
> This result does reflect the *intended and documented* behavior of the
> elementsEqual(_:) method, which performs a *lexicographical* elementwise
> comparison. That is, the method first compares set1.first to set2.first,
> then (if the two elements compare equal) compares the next element stored
> internally in set1 to the next element stored internally in set2, and so
> on.
>
> In almost all circumstances where a set is compared to another set, or a
> dictionary is compared to another dictionary, users should use == instead
> of elementsEqual(_:).
>
> Proposed
> solution
>
> The proposed solution is the result of an iterative process of reasoning,
> presented here:
>
> The first and most obvious solution is to remove the elementsEqual(_:)
> method altogether in favor of ==. This prevents its misuse. However,
> because elementsEqual(_:) is a generic method on Sequence, we can use it
> to compare an instance of UnsafeBufferPointer to an instance of [Int].
> This is a useful and non-redundant feature which would be eliminated if the
> method is removed altogether.
>
> A second solution  is to
> create overloads that forbid the use of the 

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

[Xiaodi Wu via swift-evolution]

On Fri, Oct 13, 2017 at 12:12 PM, Kevin Nattinger 
wrote:

>
> On Oct 13, 2017, at 10:01 AM, Michael Ilseman  wrote:
>
>
>
> On Oct 12, 2017, at 9:57 PM, Kevin Nattinger via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> –∞
>
> 1. I strongly object to the proposed name. It doesn't make it more clear
> to me what the method does, and is misleading at best. Among other issues,
> "lexicographical" is defined as alphabet order, and (1) this method applies
> to objects that are not Strings, and (2) this method's behavior isn't any
> more well-defined for Strings, so that name is even more of a lie than the
> original.
>
>
> FWIW, in the context of String, "lexicographical ordering” does not imply
> human-written-language-alphabetical order at all, as there’s no universal
> alphabetical ordering for human language. I.e., such a concrete notion for
> Strings does not exist, not even theoretically. “Lexicographical” derives
> its meaning from the mathematical usage[1] which uses that term as well as
> “alphabet” without being restricted to human-written-language, in which it
> means some total ordering over a finite set.
>
> [1] https://en.wikipedia.org/wiki/Lexicographical_order
>
>
> I see, apologies for the mistake.
> Regardless of the specific type of ordering, lexicographicallyEquals says
> to me that the objects should be sorted into lexicographical order and
> compared. Precisely the opposite of the proposal.
>

That is an interesting interpretation. I suppose anyone has the right to
interpret anything in any way they please, but this seems a uniquely
idiosyncratic interpretation. The total ordering is over the set of all
sequences, and the comparison is between two sequences--note that the
function name uses the singular ("equals") and makes no reference to the
lexicography or ordering of elements. Likewise, dictionaries don't sort
"hello" and "world" by comparing "ehllo" and "dlorw".


>
>
> 2. This is really just a symptom of a bigger problem. The fact that two
> Sets can compare equal and yet return different results for that method
> (among too many others) is logically inconsistent and points to a much
> deeper issue with Set and Sequence. It is probably about 3 releases too
> late to get this straightened out properly, but I'll outline the real issue
> in case someone has an idea for fixing it.
>
> *The root of the problem is that Set conforms to Sequence, but Sequence
> doesn't require a well-defined order.* Since Set doesn't have a
> well-defined order, a significant portion of its interface is unspecified.
> The methods are implemented because they have to be, but they doesn't have
> well-defined or necessarily consistent results.
>
> A sequence is, by definition, ordered. That is reflected in the fact that
> over half the methods in the main Sequence definition* make no sense and
> are not well-defined unless there is a well-defined order to the sequence
> itself. What does it even mean to `dropFirst()` in a Set? The fact that two
> objects that compare equal can give different results for a 100% deterministic
> function is illogical, nonsensical, and dangerous.
>
> * 7/12 by my count, ignoring `_*` funcs but including the `var`
>
> The current contents of Sequence can be cleanly divided into two groups;
> those that return SubSequence imply a specific ordering, and the
> rest do not.
>
>  I think those should be/should have been two separate protocols:
>
> public protocol Iterable {
>   associatedtype Iterator: IteratorProtocol
>   func map(...) -> [T] // Iterable where .Iterator.Element == T
>   func filter(...) -> [Iterator.Element] // Iterable where
> .Iterator.Element == Self.Iterator.Element
>   func forEach(...)
>   func makeIterator() -> Iterator
>   var underestimatedCount: Int { get }
> }
>
> public protocol Sequence: Iterable { // Maybe OrderedSequence just to
> make the well-defined-order requirement explicit
>   associatedtype SubSequence
>   func dropFirst(...)   -> SubSequence   // Sequence where
> .Iterator.Element == Self.Iterator.Element
>   func dropLast(...)-> SubSequence   //" "
>   func drop(while...)   -> SubSequence   //" "
>   func prefix(...)  -> SubSequence   //" "
>   func prefix(while...) -> SubSequence   //" "
>   func suffix(...)  -> SubSequence   //" "
>   func split(...where...)  -> [SubSequence] // Iterable where
> .Iterator.Element == (Sequence where .Iterator.Element ==
> Self.Iterator.Element)
> }
>
> (The comments, of course, would be more sensible types once the ideas can
> actually be expressed in Swift)
>
> Then unordered collections (Set and Dictionary) would just conform to
> Iterable and not Sequence, so ALL the methods on those classes would make
> logical sense and have well-defined behavior; no change would be
> needed for ordered collections.
>
> Now, the practical matter. If this were Swift 1->2 or 2->3, I doubt there
> would be a significant issue with actually 

Re: [swift-evolution] commas optional

[Chris Lattner via swift-evolution]

> On Oct 13, 2017, at 10:43 AM, Jarod Long via swift-evolution 
>  wrote:
> 
> Ahh, yeah, that does seem like a much trickier case to avoid breaking. My 
> instinct says it's still possible to avoid, but maybe not without lots of 
> complexity.

We already have whitespace sensitive rules to handle this.  There is no 
fundamental implementation difference that I see between separating the 
elements of lists (which are expressions) and the elements of statements (which 
can be expressions):

func foo() -> Int { … }

func statements() {
  foo()
  foo()
}

let list = [
  foo()
  foo()
]

That said, I still believe that it would be premature to "syntax optimize" this 
at this point in Swift’s evolution.

-Chris



> 
> Jarod
> 
> On Oct 12, 2017, 16:21 -0700, Xiaodi Wu , wrote:
>> On Thu, Oct 12, 2017 at 2:47 PM, Jarod Long via swift-evolution 
>> > wrote:
>> I don't really expect this sort of syntactic sugar to be popular enough to 
>> make it through swift-evolution, and I don't think it's worth the 
>> distraction from more important priorities at this time, but for what it's 
>> worth, I've enjoyed this feature in other languages that support it. It 
>> plays a small part in making code more focused by eliminating unnecessary 
>> syntax.
>> 
>> I could be wrong, but I'm not so sure that this would actually be source 
>> breaking. Even if you have something like this:
>> 
>> let points = [
>> Point(
>> x: 1.0,
>> y: 2.0
>> ),
>> Point(
>> x: 3.0,
>> y: 4.0
>> )
>> ]
>> 
>> Proper implementation of this feature wouldn't suddenly interpret `Point(` 
>> as its own element.
>> 
>> There are those of us who respect the 80-character line and break 
>> expressions across lines:
>> 
>> let x = [
>>   NSVeryVeryVeryLongType
>> .veryVeryVeryLongProperty +
>>   NSVeryVeryVeryLongType2
>> .veryVeryVeryLongProperty2,
>> ]
>> 
>> It would be a pleasant surprise if a grammar with optional commas can avoid 
>> blowing up existing code; I'm quite doubtful.
>> 
>> 
>> On Oct 12, 2017, 12:23 -0700, Josh Parmenter via swift-evolution 
>> >, wrote:
>>> 
>>> 
>>> On Oct 12, 2017, at 12:17 PM, Kelvin Ma via swift-evolution 
>>> >> >> >> wrote:
>>> 
>>> a semicolon is a purely syntactic delimiter, the comma on the other hand 
>>> corresponds to physical elements in a collection. I think the two are more 
>>> different than you suggest.
>>> 
>>> 
>>> I very much agree^
>>> 
>>> Josh
>>> 
>>> 
>>> 
>>> Joshua Parmenter | Engineering Lead, Apple Technologies
>>> 
>>> T 248 777  
>>> C 206 437 1551 
>>> F 248 616 1980 
>>> www.vectorform.com >> 
>>> 
>>> Vectorform
>>> 2211 5th Ave Suite 201
>>> Seattle, WA 98121 USA
>>> 
>>> Think Tank. Lab. Studio.
>>> We invent digital products and experiences.
>>> 
>>> SEATTLE | DETROIT | NEW YORK | MUNICH | HYDERABAD
>>> ___
>>> 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 
>> 
>> 
>> 
> ___
> 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

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

[Xiaodi Wu via swift-evolution]

On Fri, Oct 13, 2017 at 10:28 AM, Adam Kemp  wrote:

>
>
> --
> Adam Kemp
>
> On Oct 13, 2017, at 7:59 AM, Xiaodi Wu  wrote:
>
> On Fri, Oct 13, 2017 at 09:02 Adam Kemp  wrote:
>
>> Right, but if you do look it up you get a bunch of things talking about
>> sorting words.
>>
>
> And that’s a perfect description of the behavior. It’s a lexicographical
> comparison operation!
>
>
> Is it? Are we always comparing words?
>

Let me clarify what I meant: the way in which a dictionary orders words is
an excellent and widely understood analog simulacrum of lexicographical
comparison. As others have already said, lexicographical comparison is an
established term for comparing sequences. Not only has such usage been long
established in Swift itself (`lexicographicallyPrecedes`), it is also
shared with other languages (C++ has `std::lexicographical_compare`), and
it originates in mathematical terminology that looked to dictionaries as
inspiration for the term.

How about pairwiseEqual?
>>
>
> A lexicographical comparison compares not merely pairwise, but in order
> from the first item onwards, and stops at the first unequal pair.
> Proceeding in order is key information, while stopping early on false is a
> nice-to-have. There’s already a word for this, and it’s “lexicographical.”
> And the analogy is universally understood: everyone has used a dictionary
> or index.
>
>
> Clearly it’s not. You have several people telling you they don’t think
> it’s clear. You can argue that it’s technically correct if you want, but
> don’t try to tell us everyone understands it when it’s obvious that’s not
> true.
>

I'm saying that essentially everyone here understands the process by which
a dictionary arranges words; I hope we can accept this to be true without a
detailed inquiry. It is not strictly the aim of this proposal to make the
actual behavior of this function "clear" to any person who sees it, though
it would be nice as a bonus; the primary aim is to alleviate the situation
as it stands now where people see this function and _clearly believe it to
be what it is not_. That the proposed name is obtuse is intentional--as
Nate has surmised--as a way to prompt the unfamiliar user to look up the
documentation. The secondary aim is to have the name be unimpeachably
technically correct, and to avoid inventing new names for it; that way,
once the user has looked up this term, it will be knowledge transferrable
to other settings (e.g., C++), and if a user has learned about this
terminology elsewhere, they will be rewarded with having that knowledge
applicable to Swift.


>> On Oct 13, 2017, at 5:17 AM, Xiaodi Wu  wrote:
>>
>> “Lexicographical comparison” is a pretty standard term, and easy to
>> Google. We didn’t make it up for Swift :)
>>
>> Since Swift names this protocol Sequence, something named
>> “Sequence.sequenceEqual” cannot distinguish this method from ==.
>>
>>
>> On Fri, Oct 13, 2017 at 01:28 Adam Kemp  wrote:
>>
>>> I agree that the proposed name is a poor choice. If we just focus on
>>> the naming part, there is precedent in other languages for the name
>>> “sequenceEqual”. I think that name makes it a bit clearer that the result
>>> is whether the sequences match pair wise rather than whether they have the
>>> same elements irrespective of order. I don’t think it entirely solves the
>>> problem, but I like it a lot better than the proposed name.
>>>
>>> --
>>> Adam Kemp
>>>
>>> On Oct 12, 2017, at 9:57 PM, Kevin Nattinger via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> –∞
>>>
>>> 1. I strongly object to the proposed name. It doesn't make it more clear
>>> to me what the method does, and is misleading at best. Among other issues,
>>> "lexicographical" is defined as alphabet order, and (1) this method applies
>>> to objects that are not Strings, and (2) this method's behavior isn't any
>>> more well-defined for Strings, so that name is even more of a lie than the
>>> original.
>>>
>>> 2. This is really just a symptom of a bigger problem. The fact that two
>>> Sets can compare equal and yet return different results for that method
>>> (among too many others) is logically inconsistent and points to a much
>>> deeper issue with Set and Sequence. It is probably about 3 releases too
>>> late to get this straightened out properly, but I'll outline the real issue
>>> in case someone has an idea for fixing it.
>>>
>>> *The root of the problem is that Set conforms to Sequence, but Sequence
>>> doesn't require a well-defined order.* Since Set doesn't have a
>>> well-defined order, a significant portion of its interface is unspecified.
>>> The methods are implemented because they have to be, but they doesn't have
>>> well-defined or necessarily consistent results.
>>>
>>> A sequence is, by definition, ordered. That is reflected in the fact
>>> that over half the methods in the main Sequence definition* make 

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

[Brent Royal-Gordon via swift-evolution]

> On Oct 12, 2017, at 9:57 PM, Kevin Nattinger via swift-evolution 
>  wrote:
> 
> That is reflected in the fact that over half the methods in the main Sequence 
> definition* make no sense and are not well-defined unless there is a 
> well-defined order to the sequence itself. What does it even mean to 
> `dropFirst()` in a Set?

It means to skip the first element the set would normally have given you. Which 
element this will be may be arbitrary, but this is still not useless:

set.dropFirst().reduce(set.first!, …)

Even elementsEqual(_:) does tell you something potentially valuable: Whether 
two instances will end up giving the same result when processed by an 
ordering-sensitive algorithm.

We should change the name to something like orderEquals(_:), and maybe change 
the lexicographicallyPrecedes(_:) method to something analogous like 
orderPrecedes(_:), and then be done with it. 

-- 
Brent Royal-Gordon
Sent from my iPhone

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Max Moiseev via swift-evolution]

> On Oct 13, 2017, at 1:34 PM, Howard Lovatt via swift-evolution 
>  wrote:
> 
> I am very glad that this issue is getting some air time since the ‘loose’ 
> definitions in `Sequence` are a pain. 
> 
> I am in the camp that thinks the best solution is to split `Sequence`. I 
> would propose splitting into `Iterable` and `Sequence`, `Sequence` is 
> ordered. `Set` and `Dictionary` would implement `Iterable` and a `for` loop 
> would work with `Iterable`. That way only already broken code is affected. 
> 
> At present we have `Set` and `Dictionary` that are problems in the standard 
> library and this justifies the split. 
> 
> If other collection types are added to the standard library that require 
> further sub-division of sequence then split sequence further at that time. 
Unfortunately there already ‘other’ collections in the standard library, as 
Xiaodi points out, lazy collections, eager collections, finite collections, 
infinite collections…
Splitting Sequence is almost trivial, handling the consequences of this split 
downstream (in more refined protocols) is a problem.

Max

> 
> -- Howard. 
> 
> On 14 Oct 2017, at 6:41 am, Jonathan Hull via swift-evolution 
> > wrote:
> 
>> I would also expect lexicographicallyEquals to sort the elements (or 
>> otherwise create/reference a total ordering) before checking for equality.  
>> I would be more surprised by the behavior of a function named this than 
>> elementsEqual.
>> 
>> Given the name, I would expect elementsEqual to return true if two sequences 
>> have the same elements, regardless of ordering (this would be a valuable 
>> function IMHO).  I would expect lexicographicallyEquals to compare the 
>> elements in some lexicographical order defined for the type which overrides 
>> the internal ordering of the sequence.
>> 
>> Kevin is right… the real answer is that the actual intended function really 
>> shouldn’t exist on unordered sequences.
>> 
>> Thanks,
>> Jon
>> 
>>> On Oct 13, 2017, at 10:12 AM, Kevin Nattinger via swift-evolution 
>>> > wrote:
>>> 
 
 On Oct 13, 2017, at 10:01 AM, Michael Ilseman > wrote:
 
 
 
> On Oct 12, 2017, at 9:57 PM, Kevin Nattinger via swift-evolution 
> > wrote:
> 
> –∞
> 
> 1. I strongly object to the proposed name. It doesn't make it more clear 
> to me what the method does, and is misleading at best. Among other 
> issues, "lexicographical" is defined as alphabet order, and (1) this 
> method applies to objects that are not Strings, and (2) this method's 
> behavior isn't any more well-defined for Strings, so that name is even 
> more of a lie than the original.
> 
 
 FWIW, in the context of String, "lexicographical ordering” does not imply 
 human-written-language-alphabetical order at all, as there’s no universal 
 alphabetical ordering for human language. I.e., such a concrete notion for 
 Strings does not exist, not even theoretically. “Lexicographical” derives 
 its meaning from the mathematical usage[1] which uses that term as well as 
 “alphabet” without being restricted to human-written-language, in which it 
 means some total ordering over a finite set.
 
 [1] https://en.wikipedia.org/wiki/Lexicographical_order 
 
>>> I see, apologies for the mistake. 
>>> Regardless of the specific type of ordering, lexicographicallyEquals says 
>>> to me that the objects should be sorted into lexicographical order and 
>>> compared. Precisely the opposite of the proposal.
>>> 
 
> 2. This is really just a symptom of a bigger problem. The fact that two 
> Sets can compare equal and yet return different results for that method 
> (among too many others) is logically inconsistent and points to a much 
> deeper issue with Set and Sequence. It is probably about 3 releases too 
> late to get this straightened out properly, but I'll outline the real 
> issue in case someone has an idea for fixing it.
> 
> The root of the problem is that Set conforms to Sequence, but Sequence 
> doesn't require a well-defined order. Since Set doesn't have a 
> well-defined order, a significant portion of its interface is 
> unspecified. The methods are implemented because they have to be, but 
> they doesn't have well-defined or necessarily consistent results.
> 
> A sequence is, by definition, ordered. That is reflected in the fact that 
> over half the methods in the main Sequence definition* make no sense and 
> are not well-defined unless there is a well-defined order to the sequence 
> itself. What does it even mean to `dropFirst()` in a Set? The 

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Mike Kluev via swift-evolution]

On 13 October 2017 at 22:50, Jean-Daniel  wrote:

I mean:
>
> func foo() -> Int { … }
>
> func bar(callback: () -> discardable Int) { … }
>
> bar(foo) // does it warns ?
> bar({ 3 }) // does it warns ? If it does, how to avoid it ?
>

thanks.

>>> And allowing it in signature but not in lambda would be confusing.

not any more confusing than it is now (allowing @discardableResult before
function name and not allowing it before closure parameters).

but, if to fix that, than could be this (orthogonal to whether it is
"@discardableResult" or "discardable"):

func foo() -> Int {}
func bar(_ callback: () -> discardable Int) {}

bar(foo) // error, type mismatch
bar({ 3 }) // error, type mismatch
bar({ () -> discardable Int in 3 }) // ok, types matched

- and -

func poo() -> discardable Int {}
func baz(_ callback: () -> Int) {}

baz(poo) // ok, types compatible
baz({ 3 }) // ok, types matched
baz({ () -> discardable Int in 3 }) // ok, types compatible

Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Christopher Whidden via swift-evolution]

Using the term “lexicographically” implies to me that the Element type must 
conform to Comparable, as would be required for a total order.  The Sequence 
method you mention, lexicographicallyPrecedes(_:), does have this constraint, 
whereas the method in question for elementsEqual(_:) / 
lexicographicallyEquals(_:) only has the constraint that the Element is 
Equatable.  As an example, an array of simple enums has no default 
lexicographical ordering but is still able to use this method because enums 
(without associated values) are Equatable by default:

enum Foo {
case bar
case baz
}

let f1 = [Foo.bar, Foo.baz]
let f2 = [Foo.baz, Foo.bar]

f1.elementsEqual(f2) //false
f1.elementsEqual(f2.reversed()) //true

I also share Jonathan’s concerns that some programmers may misinterpret 
[lexicographically][Equals] to mean [sorted in lexicographical order][compare 
sequence equality], which is not what the method in question does.

Xiaodi, I think you are right that Sequence.sequentiallyEquals is to close to 
"==" to use, but I think we have to find something better here.

I’ll recommend that we use the name Sequence.iterativelyEquals(_:) since this 
describes the body of the method concisely.  A rough abbreviation of this 
algorithm is:

1. Iterate over elements in two sequences
a. Compare elements for equality

“iterativelyEquals" concisely describes this.

> On Oct 12, 2017, at 6:24 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Rename Sequence.elementsEqual
> 
> Proposal: SE- 
> Authors: Xiaodi Wu 
> Review Manager: TBD
> Status: Awaiting review
>  
> Introduction
> 
> The current behavior of Sequence.elementsEqual is potentially confusing to 
> users given its name. Having surveyed the alternative solutions to this 
> problem, it is proposed that the method be renamed to 
> Sequence.lexicographicallyEquals.
> 
>  
> Motivation
> 
> As outlined by Ole Begemann 
> , use of 
> Sequence.elementsEqual(_:) can lead to surprising results if the sequences 
> compared are unordered:
> 
> var set1: Set = Set(1...5)
> var set2: Set = Set((1...5).reversed())
> 
> set1 == set2 // true
> set1.elementsEqual(set2) // false
> This result does reflect the intended and documented behavior of the 
> elementsEqual(_:) method, which performs a lexicographical elementwise 
> comparison. That is, the method first compares set1.first to set2.first, then 
> (if the two elements compare equal) compares the next element stored 
> internally in set1 to the next element stored internally in set2, and so on.
> 
> In almost all circumstances where a set is compared to another set, or a 
> dictionary is compared to another dictionary, users should use == instead of 
> elementsEqual(_:).
> 
>  
> Proposed
>  solution
> 
> The proposed solution is the result of an iterative process of reasoning, 
> presented here:
> 
> The first and most obvious solution is to remove the elementsEqual(_:) method 
> altogether in favor of ==. This prevents its misuse. However, because 
> elementsEqual(_:) is a generic method on Sequence, we can use it to compare 
> an instance of UnsafeBufferPointer to an instance of [Int]. This is a 
> useful and non-redundant feature which would be eliminated if the method is 
> removed altogether.
> 
> A second solution  is to create 
> overloads that forbid the use of the elementsEqual(_:) method specifically in 
> non-generic code. This would prevent misuse in non-generic code; however, it 
> would also forbid legitimate mixed-type comparisons in non-generic code while 
> failing to prevent misuse in generic code. The solution also creates a 
> difference in the behavior of generic and non-generic code calling the same 
> method, which is potentially confusing, without solving the problem 
> completely.
> 
> A third solution is to dramatically overhaul the protocol hierarchy for Swift 
> sequences and collections so that unordered collections no longer have 
> members such as first and elementsEqual(_:). However, this would be a 
> colossal and source-breaking undertaking, and it is unlikely to be 
> satisfactory in addressing all the axes of differences among sequence and 
> collection types:
> 
> Finite versus infinite
> Single-pass versus multi-pass
> Ordered versus unordered
> Lazy versus eager
> Forward/bidirectional/random-access
> A fourth solution is proposed here. It is predicated on the following 
> observation:
> 
> Another method similar to elementsEqual(_:) already exists on Sequence named 
> lexicographicallyPrecedes(_:). Like first, 

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Jean-Daniel via swift-evolution]

> Le 13 oct. 2017 à 23:23, Mike Kluev via swift-evolution 
>  a écrit :
> 
> On 13 October 2017 at 21:15, Jean-Daniel  > wrote:
> I don’t think this is a good idea to make discardable part of the function 
> type.
> 
> What would fun(callback: () -> discardable Int) would means ? 
> 
> you mean this?
> 
> func foo(callback: () -> discardable Int) {
> ...
> let x = callback()
> ...
> callback() // no warning or error here
> }
> 
> Mike
> 

I mean:

func foo() -> Int { … }

func bar(callback: () -> discardable Int) { … }

bar(foo) // does it warns ?
bar({ 3 }) // does it warns ? If it does, how to avoid it ?


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Mike Kluev via swift-evolution]

On 13 October 2017 at 21:15, Jean-Daniel  wrote:

> I don’t think this is a good idea to make discardable part of the function
> type.
>
> What would fun(callback: () -> discardable Int) would means ?
>

you mean this?

func foo(callback: () -> discardable Int) {
...
let x = callback()
...
callback() // no warning or error here
}

Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Howard Lovatt via swift-evolution]

I am very glad that this issue is getting some air time since the ‘loose’ 
definitions in `Sequence` are a pain. 

I am in the camp that thinks the best solution is to split `Sequence`. I would 
propose splitting into `Iterable` and `Sequence`, `Sequence` is ordered. `Set` 
and `Dictionary` would implement `Iterable` and a `for` loop would work with 
`Iterable`. That way only already broken code is affected. 

At present we have `Set` and `Dictionary` that are problems in the standard 
library and this justifies the split. 

If other collection types are added to the standard library that require 
further sub-division of sequence then split sequence further at that time. 

-- Howard. 

> On 14 Oct 2017, at 6:41 am, Jonathan Hull via swift-evolution 
>  wrote:
> 
> I would also expect lexicographicallyEquals to sort the elements (or 
> otherwise create/reference a total ordering) before checking for equality.  I 
> would be more surprised by the behavior of a function named this than 
> elementsEqual.
> 
> Given the name, I would expect elementsEqual to return true if two sequences 
> have the same elements, regardless of ordering (this would be a valuable 
> function IMHO).  I would expect lexicographicallyEquals to compare the 
> elements in some lexicographical order defined for the type which overrides 
> the internal ordering of the sequence.
> 
> Kevin is right… the real answer is that the actual intended function really 
> shouldn’t exist on unordered sequences.
> 
> Thanks,
> Jon
> 
>>> On Oct 13, 2017, at 10:12 AM, Kevin Nattinger via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Oct 13, 2017, at 10:01 AM, Michael Ilseman  wrote:
 
 
 
 On Oct 12, 2017, at 9:57 PM, Kevin Nattinger via swift-evolution 
  wrote:
 
 –∞
 
 1. I strongly object to the proposed name. It doesn't make it more clear 
 to me what the method does, and is misleading at best. Among other issues, 
 "lexicographical" is defined as alphabet order, and (1) this method 
 applies to objects that are not Strings, and (2) this method's behavior 
 isn't any more well-defined for Strings, so that name is even more of a 
 lie than the original.
 
>>> 
>>> FWIW, in the context of String, "lexicographical ordering” does not imply 
>>> human-written-language-alphabetical order at all, as there’s no universal 
>>> alphabetical ordering for human language. I.e., such a concrete notion for 
>>> Strings does not exist, not even theoretically. “Lexicographical” derives 
>>> its meaning from the mathematical usage[1] which uses that term as well as 
>>> “alphabet” without being restricted to human-written-language, in which it 
>>> means some total ordering over a finite set.
>>> 
>>> [1] https://en.wikipedia.org/wiki/Lexicographical_order
>> 
>> I see, apologies for the mistake. 
>> Regardless of the specific type of ordering, lexicographicallyEquals says to 
>> me that the objects should be sorted into lexicographical order and 
>> compared. Precisely the opposite of the proposal.
>> 
>>> 
 2. This is really just a symptom of a bigger problem. The fact that two 
 Sets can compare equal and yet return different results for that method 
 (among too many others) is logically inconsistent and points to a much 
 deeper issue with Set and Sequence. It is probably about 3 releases too 
 late to get this straightened out properly, but I'll outline the real 
 issue in case someone has an idea for fixing it.
 
 The root of the problem is that Set conforms to Sequence, but Sequence 
 doesn't require a well-defined order. Since Set doesn't have a 
 well-defined order, a significant portion of its interface is unspecified. 
 The methods are implemented because they have to be, but they doesn't have 
 well-defined or necessarily consistent results.
 
 A sequence is, by definition, ordered. That is reflected in the fact that 
 over half the methods in the main Sequence definition* make no sense and 
 are not well-defined unless there is a well-defined order to the sequence 
 itself. What does it even mean to `dropFirst()` in a Set? The fact that 
 two objects that compare equal can give different results for a 100% 
 deterministic function is illogical, nonsensical, and dangerous.
 
 * 7/12 by my count, ignoring `_*` funcs but including the `var`
 
 The current contents of Sequence can be cleanly divided into two groups; 
 those that return SubSequence imply a specific ordering, and the rest do 
 not.
 
  I think those should be/should have been two separate protocols:
 
 public protocol Iterable {
   associatedtype Iterator: IteratorProtocol
   func map(...) -> [T] // Iterable where .Iterator.Element == T
   func filter(...) -> [Iterator.Element] // Iterable where 
 

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Jean-Daniel via swift-evolution]

I don’t think this is a good idea to make discardable part of the function type.

What would fun(callback: () -> discardable Int) would means ? 

And allowing it in signature but not in lambda would be confusing.


> Le 12 oct. 2017 à 15:32, Mike Kluev via swift-evolution 
>  a écrit :
> 
> On 12 October 2017 at 14:14, David James  > wrote:
> True, and it was making the method signature too long. But at least I have 
> the option to do that. If we move the annotation to just before the return 
> type, then we have no choice.
> 
> you can still put it on the next line along with the result :)
> 
> imho, this shall not be a decision maker nowadays (20 years ago it would).
> 
> Mike
> 
> ___
> 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

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

[Jonathan Hull via swift-evolution]

It has been a while, but I believe a lexicographical ordering is basically a 
mapping from a set to the natural numbers (which should, in effect, provide a 
total ordering).  The mapping itself can be arbitrary, but the same set of 
things should never map to two different sequences (which just happens to be 
the example given).

This tells me that “lexicographicallyPrecedes” is actually misnamed unless it 
refers to something which has a defined totally ordering.

If we are looking to rename elementsEqual (which I would expect to check if the 
same elements are present regardless of ordering), I would recommend 
elementOrderingEqual or something like that that references that the answer 
will be affected by the internal representation/ordering of the sequence.

Thanks,
Jon

> On Oct 13, 2017, at 11:10 AM, Jarod Long via swift-evolution 
>  wrote:
> 
> The name that feels natural to me would be `sequentiallyEquals`. I don't 
> dispute that the term "lexicographical" is used correctly here, although at 
> least for me personally, it's not a word that I encounter frequently enough 
> to understand what this method would do without reading the documentation. 
> Like Kevin, if I were to guess what the method did without checking, I would 
> probably think that it compared lexicographically-sorted versions of the 
> collections.
> 
> But the consistency with `lexicographicallyPrecedes` is a pretty strong 
> argument, although `sequentiallyPrecedes` would also feel more natural to me 
> there, and my suspicion about the mentioned lack of evidence that the method 
> has been a pitfall for users is that it's not actually used often enough out 
> in the wild to have heard much about it. That's just a guess though. This 
> proposal is the first time I've learned of its existence.
> 
> In any case, my ideal version of this proposal would use `sequentiallyEquals` 
> and also rename `lexicographicallyPrecedes` to `sequentiallyPrecedes`, but I 
> still like the proposal overall as-is. Thanks for bringing it forward!
> 
> Jarod
> 
> On Oct 12, 2017, 16:24 -0700, Xiaodi Wu via swift-evolution 
> , wrote:
>> Rename Sequence.elementsEqual
>> 
>> Proposal: SE- 
>> Authors: Xiaodi Wu 
>> Review Manager: TBD
>> Status: Awaiting review
>>  
>> Introduction
>> 
>> The current behavior of Sequence.elementsEqual is potentially confusing to 
>> users given its name. Having surveyed the alternative solutions to this 
>> problem, it is proposed that the method be renamed to 
>> Sequence.lexicographicallyEquals.
>> 
>>  
>> Motivation
>> 
>> As outlined by Ole Begemann 
>> , use of 
>> Sequence.elementsEqual(_:) can lead to surprising results if the sequences 
>> compared are unordered:
>> 
>> var set1: Set = Set(1...5)
>> var set2: Set = Set((1...5).reversed())
>> 
>> set1 == set2 // true
>> set1.elementsEqual(set2) // false
>> This result does reflect the intended and documented behavior of the 
>> elementsEqual(_:) method, which performs a lexicographical elementwise 
>> comparison. That is, the method first compares set1.first to set2.first, 
>> then (if the two elements compare equal) compares the next element stored 
>> internally in set1 to the next element stored internally in set2, and so on.
>> 
>> In almost all circumstances where a set is compared to another set, or a 
>> dictionary is compared to another dictionary, users should use == instead of 
>> elementsEqual(_:).
>> 
>>  
>> Proposed
>>  solution
>> 
>> The proposed solution is the result of an iterative process of reasoning, 
>> presented here:
>> 
>> The first and most obvious solution is to remove the elementsEqual(_:) 
>> method altogether in favor of ==. This prevents its misuse. However, because 
>> elementsEqual(_:) is a generic method on Sequence, we can use it to compare 
>> an instance of UnsafeBufferPointer to an instance of [Int]. This is a 
>> useful and non-redundant feature which would be eliminated if the method is 
>> removed altogether.
>> 
>> A second solution  is to create 
>> overloads that forbid the use of the elementsEqual(_:) method specifically 
>> in non-generic code. This would prevent misuse in non-generic code; however, 
>> it would also forbid legitimate mixed-type comparisons in non-generic code 
>> while failing to prevent misuse in generic code. The solution also creates a 
>> difference in the behavior of generic and non-generic code calling the same 
>> method, which is potentially confusing, without solving the problem 
>> completely.
>> 
>> A third solution is to 

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

[Jonathan Hull via swift-evolution]

I would also expect lexicographicallyEquals to sort the elements (or otherwise 
create/reference a total ordering) before checking for equality.  I would be 
more surprised by the behavior of a function named this than elementsEqual.

Given the name, I would expect elementsEqual to return true if two sequences 
have the same elements, regardless of ordering (this would be a valuable 
function IMHO).  I would expect lexicographicallyEquals to compare the elements 
in some lexicographical order defined for the type which overrides the internal 
ordering of the sequence.

Kevin is right… the real answer is that the actual intended function really 
shouldn’t exist on unordered sequences.

Thanks,
Jon

> On Oct 13, 2017, at 10:12 AM, Kevin Nattinger via swift-evolution 
>  wrote:
> 
>> 
>> On Oct 13, 2017, at 10:01 AM, Michael Ilseman > > wrote:
>> 
>> 
>> 
>>> On Oct 12, 2017, at 9:57 PM, Kevin Nattinger via swift-evolution 
>>> > wrote:
>>> 
>>> –∞
>>> 
>>> 1. I strongly object to the proposed name. It doesn't make it more clear to 
>>> me what the method does, and is misleading at best. Among other issues, 
>>> "lexicographical" is defined as alphabet order, and (1) this method applies 
>>> to objects that are not Strings, and (2) this method's behavior isn't any 
>>> more well-defined for Strings, so that name is even more of a lie than the 
>>> original.
>>> 
>> 
>> FWIW, in the context of String, "lexicographical ordering” does not imply 
>> human-written-language-alphabetical order at all, as there’s no universal 
>> alphabetical ordering for human language. I.e., such a concrete notion for 
>> Strings does not exist, not even theoretically. “Lexicographical” derives 
>> its meaning from the mathematical usage[1] which uses that term as well as 
>> “alphabet” without being restricted to human-written-language, in which it 
>> means some total ordering over a finite set.
>> 
>> [1] https://en.wikipedia.org/wiki/Lexicographical_order 
>> 
> I see, apologies for the mistake. 
> Regardless of the specific type of ordering, lexicographicallyEquals says to 
> me that the objects should be sorted into lexicographical order and compared. 
> Precisely the opposite of the proposal.
> 
>> 
>>> 2. This is really just a symptom of a bigger problem. The fact that two 
>>> Sets can compare equal and yet return different results for that method 
>>> (among too many others) is logically inconsistent and points to a much 
>>> deeper issue with Set and Sequence. It is probably about 3 releases too 
>>> late to get this straightened out properly, but I'll outline the real issue 
>>> in case someone has an idea for fixing it.
>>> 
>>> The root of the problem is that Set conforms to Sequence, but Sequence 
>>> doesn't require a well-defined order. Since Set doesn't have a well-defined 
>>> order, a significant portion of its interface is unspecified. The methods 
>>> are implemented because they have to be, but they doesn't have well-defined 
>>> or necessarily consistent results.
>>> 
>>> A sequence is, by definition, ordered. That is reflected in the fact that 
>>> over half the methods in the main Sequence definition* make no sense and 
>>> are not well-defined unless there is a well-defined order to the sequence 
>>> itself. What does it even mean to `dropFirst()` in a Set? The fact that two 
>>> objects that compare equal can give different results for a 100% 
>>> deterministic function is illogical, nonsensical, and dangerous.
>>> 
>>> * 7/12 by my count, ignoring `_*` funcs but including the `var`
>>> 
>>> The current contents of Sequence can be cleanly divided into two groups; 
>>> those that return SubSequence imply a specific ordering, and the rest do 
>>> not.
>>> 
>>>  I think those should be/should have been two separate protocols:
>>> 
>>> public protocol Iterable {
>>>   associatedtype Iterator: IteratorProtocol
>>>   func map(...) -> [T] // Iterable where .Iterator.Element == T
>>>   func filter(...) -> [Iterator.Element] // Iterable where 
>>> .Iterator.Element == Self.Iterator.Element
>>>   func forEach(...)
>>>   func makeIterator() -> Iterator
>>>   var underestimatedCount: Int { get }
>>> }
>>> 
>>> public protocol Sequence: Iterable { // Maybe OrderedSequence just to make 
>>> the well-defined-order requirement explicit
>>>   associatedtype SubSequence
>>>   func dropFirst(...)   -> SubSequence   // Sequence where 
>>> .Iterator.Element == Self.Iterator.Element
>>>   func dropLast(...)-> SubSequence   //" "
>>>   func drop(while...)   -> SubSequence   //" "
>>>   func prefix(...)  -> SubSequence   //" "
>>>   func prefix(while...) -> SubSequence   //" "
>>>   func suffix(...)  -> SubSequence   //" "
>>>   func split(...where...)  -> [SubSequence] // Iterable where 
>>> 

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

[Kevin Nattinger via swift-evolution]

> 
> Is seems like you’re arguing we should attack the “Ordered versus unordered” 
> dichotomy prior to any name change. Is that correct?
> 

Yes, that's exactly my primary argument. 

(The secondary argument being that in either case the name should not be 
changed, at least not to the proposed one.)

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Michael Ilseman via swift-evolution]

> On Oct 13, 2017, at 10:12 AM, Kevin Nattinger  wrote:
> 
>> 
>> On Oct 13, 2017, at 10:01 AM, Michael Ilseman > > wrote:
>> 
>> 
>> 
>>> On Oct 12, 2017, at 9:57 PM, Kevin Nattinger via swift-evolution 
>>> > wrote:
>>> 
>>> –∞
>>> 
>>> 1. I strongly object to the proposed name. It doesn't make it more clear to 
>>> me what the method does, and is misleading at best. Among other issues, 
>>> "lexicographical" is defined as alphabet order, and (1) this method applies 
>>> to objects that are not Strings, and (2) this method's behavior isn't any 
>>> more well-defined for Strings, so that name is even more of a lie than the 
>>> original.
>>> 
>> 
>> FWIW, in the context of String, "lexicographical ordering” does not imply 
>> human-written-language-alphabetical order at all, as there’s no universal 
>> alphabetical ordering for human language. I.e., such a concrete notion for 
>> Strings does not exist, not even theoretically. “Lexicographical” derives 
>> its meaning from the mathematical usage[1] which uses that term as well as 
>> “alphabet” without being restricted to human-written-language, in which it 
>> means some total ordering over a finite set.
>> 
>> [1] https://en.wikipedia.org/wiki/Lexicographical_order 
>> 
> I see, apologies for the mistake. 

No worries, I think my comment came across too blunt. Sorry about that. I was 
trying to defend the word “lexicographical” which I think is a very useful word 
to have at our disposal :-)

> Regardless of the specific type of ordering, lexicographicallyEquals says to 
> me that the objects should be sorted into lexicographical order and compared. 
> Precisely the opposite of the proposal.
> 

Right, and thus cuts to the heart of what Xiaodi raised in the proposal’s third 
potential solution.

Quoted from the proposal:
> A third solution is to dramatically overhaul the protocol hierarchy for Swift 
> sequences and collections so that unordered collections no longer have 
> members such as first and elementsEqual(_:). However, this would be a 
> colossal and source-breaking undertaking, and it is unlikely to be 
> satisfactory in addressing all the axes of differences among sequence and 
> collection types:
> 
> Finite versus infinite
> Single-pass versus multi-pass
> Ordered versus unordered
> Lazy versus eager
> Forward/bidirectional/random-access

Is seems like you’re arguing we should attack the “Ordered versus unordered” 
dichotomy prior to any name change. Is that correct?


>> 
>>> 2. This is really just a symptom of a bigger problem. The fact that two 
>>> Sets can compare equal and yet return different results for that method 
>>> (among too many others) is logically inconsistent and points to a much 
>>> deeper issue with Set and Sequence. It is probably about 3 releases too 
>>> late to get this straightened out properly, but I'll outline the real issue 
>>> in case someone has an idea for fixing it.
>>> 
>>> The root of the problem is that Set conforms to Sequence, but Sequence 
>>> doesn't require a well-defined order. Since Set doesn't have a well-defined 
>>> order, a significant portion of its interface is unspecified. The methods 
>>> are implemented because they have to be, but they doesn't have well-defined 
>>> or necessarily consistent results.
>>> 
>>> A sequence is, by definition, ordered. That is reflected in the fact that 
>>> over half the methods in the main Sequence definition* make no sense and 
>>> are not well-defined unless there is a well-defined order to the sequence 
>>> itself. What does it even mean to `dropFirst()` in a Set? The fact that two 
>>> objects that compare equal can give different results for a 100% 
>>> deterministic function is illogical, nonsensical, and dangerous.
>>> 
>>> * 7/12 by my count, ignoring `_*` funcs but including the `var`
>>> 
>>> The current contents of Sequence can be cleanly divided into two groups; 
>>> those that return SubSequence imply a specific ordering, and the rest do 
>>> not.
>>> 
>>>  I think those should be/should have been two separate protocols:
>>> 
>>> public protocol Iterable {
>>>   associatedtype Iterator: IteratorProtocol
>>>   func map(...) -> [T] // Iterable where .Iterator.Element == T
>>>   func filter(...) -> [Iterator.Element] // Iterable where 
>>> .Iterator.Element == Self.Iterator.Element
>>>   func forEach(...)
>>>   func makeIterator() -> Iterator
>>>   var underestimatedCount: Int { get }
>>> }
>>> 
>>> public protocol Sequence: Iterable { // Maybe OrderedSequence just to make 
>>> the well-defined-order requirement explicit
>>>   associatedtype SubSequence
>>>   func dropFirst(...)   -> SubSequence   // Sequence where 
>>> .Iterator.Element == Self.Iterator.Element
>>>   func dropLast(...)-> SubSequence   //" "
>>>   func drop(while...)   -> SubSequence   //  

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

[Jarod Long via swift-evolution]

The name that feels natural to me would be `sequentiallyEquals`. I don't 
dispute that the term "lexicographical" is used correctly here, although at 
least for me personally, it's not a word that I encounter frequently enough to 
understand what this method would do without reading the documentation. Like 
Kevin, if I were to guess what the method did without checking, I would 
probably think that it compared lexicographically-sorted versions of the 
collections.

But the consistency with `lexicographicallyPrecedes` is a pretty strong 
argument, although `sequentiallyPrecedes` would also feel more natural to me 
there, and my suspicion about the mentioned lack of evidence that the method 
has been a pitfall for users is that it's not actually used often enough out in 
the wild to have heard much about it. That's just a guess though. This proposal 
is the first time I've learned of its existence.

In any case, my ideal version of this proposal would use `sequentiallyEquals` 
and also rename `lexicographicallyPrecedes` to `sequentiallyPrecedes`, but I 
still like the proposal overall as-is. Thanks for bringing it forward!

Jarod

On Oct 12, 2017, 16:24 -0700, Xiaodi Wu via swift-evolution 
, wrote:
> Rename Sequence.elementsEqual
>
> • Proposal: SE-
> • Authors: Xiaodi Wu
> • Review Manager: TBD
> • Status: Awaiting review
>
> Introduction
> The current behavior of Sequence.elementsEqual is potentially confusing to 
> users given its name. Having surveyed the alternative solutions to this 
> problem, it is proposed that the method be renamed to 
> Sequence.lexicographicallyEquals.
> Motivation
> As outlined by Ole Begemann, use of Sequence.elementsEqual(_:) can lead to 
> surprising results if the sequences compared are unordered:
> var set1: Set = Set(1...5)
> var set2: Set = Set((1...5).reversed())
>
> set1 == set2 // true
> set1.elementsEqual(set2) // false
> This result does reflect the intended and documented behavior of the 
> elementsEqual(_:) method, which performs a lexicographical elementwise 
> comparison. That is, the method first compares set1.first to set2.first, then 
> (if the two elements compare equal) compares the next element stored 
> internally in set1 to the next element stored internally in set2, and so on.
> In almost all circumstances where a set is compared to another set, or a 
> dictionary is compared to another dictionary, users should use == instead of 
> elementsEqual(_:).
> Proposed solution
> The proposed solution is the result of an iterative process of reasoning, 
> presented here:
> The first and most obvious solution is to remove the elementsEqual(_:) method 
> altogether in favor of ==. This prevents its misuse. However, because 
> elementsEqual(_:) is a generic method on Sequence, we can use it to compare 
> an instance of UnsafeBufferPointer to an instance of [Int]. This is a 
> useful and non-redundant feature which would be eliminated if the method is 
> removed altogether.
> A second solution is to create overloads that forbid the use of the 
> elementsEqual(_:) method specifically in non-generic code. This would prevent 
> misuse in non-generic code; however, it would also forbid legitimate 
> mixed-type comparisons in non-generic code while failing to prevent misuse in 
> generic code. The solution also creates a difference in the behavior of 
> generic and non-generic code calling the same method, which is potentially 
> confusing, without solving the problem completely.
> A third solution is to dramatically overhaul the protocol hierarchy for Swift 
> sequences and collections so that unordered collections no longer have 
> members such as first and elementsEqual(_:). However, this would be a 
> colossal and source-breaking undertaking, and it is unlikely to be 
> satisfactory in addressing all the axes of differences among sequence and 
> collection types:
>
> • Finite versus infinite
> • Single-pass versus multi-pass
> • Ordered versus unordered
> • Lazy versus eager
> • Forward/bidirectional/random-access
>
> A fourth solution is proposed here. It is predicated on the following 
> observation:
> Another method similar to elementsEqual(_:) already exists on Sequence named 
> lexicographicallyPrecedes(_:). Like first, elementsEqual(_:), drop(while:), 
> and others, it relies on the internal order of elements in a manner that is 
> not completely suitable for an unordered collection. However, like first and 
> unlike elementsEqual(_:), this fact is called out in the name of the method; 
> unsurprisingly, like first and unlike elementsEqual(_:), there is no evidence 
> that lexicographicallyPrecedes(_:) has been a pitfall for users.
> This observation suggests that a major reason for confusion over 
> elementsEqual(_:) stems from its name. So, it is proposed that 
> elementsEqual(_:) should be renamed to lexicographicallyEquals(_:). The 
> function will remain somewhat of a poor fit for unordered collections, but no 
> more so 

Re: [swift-evolution] commas optional

[Jarod Long via swift-evolution]

Ahh, yeah, that does seem like a much trickier case to avoid breaking. My 
instinct says it's still possible to avoid, but maybe not without lots of 
complexity.

Jarod

On Oct 12, 2017, 16:21 -0700, Xiaodi Wu , wrote:
> On Thu, Oct 12, 2017 at 2:47 PM, Jarod Long via swift-evolution 
>  wrote:
> > > I don't really expect this sort of syntactic sugar to be popular enough 
> > > to make it through swift-evolution, and I don't think it's worth the 
> > > distraction from more important priorities at this time, but for what 
> > > it's worth, I've enjoyed this feature in other languages that support it. 
> > > It plays a small part in making code more focused by eliminating 
> > > unnecessary syntax.
> > >
> > > I could be wrong, but I'm not so sure that this would actually be source 
> > > breaking. Even if you have something like this:
> > >
> > > let points = [
> > >     Point(
> > >         x: 1.0,
> > >         y: 2.0
> > >     ),
> > >     Point(
> > >         x: 3.0,
> > >         y: 4.0
> > >     )
> > > ]
> > >
> > > Proper implementation of this feature wouldn't suddenly interpret 
> > > `Point(` as its own element.
> >
> > There are those of us who respect the 80-character line and break 
> > expressions across lines:
> >
> > let x = [
> >   NSVeryVeryVeryLongType
> >     .veryVeryVeryLongProperty +
> >   NSVeryVeryVeryLongType2
> >     .veryVeryVeryLongProperty2,
> > ]
> >
> > It would be a pleasant surprise if a grammar with optional commas can avoid 
> > blowing up existing code; I'm quite doubtful.
> >
> >
> > > On Oct 12, 2017, 12:23 -0700, Josh Parmenter via swift-evolution 
> > > , wrote:
> > > >
> > > >
> > > > On Oct 12, 2017, at 12:17 PM, Kelvin Ma via swift-evolution 
> > > > > wrote:
> > > >
> > > > a semicolon is a purely syntactic delimiter, the comma on the other 
> > > > hand corresponds to physical elements in a collection. I think the two 
> > > > are more different than you suggest.
> > > >
> > > >
> > > > I very much agree^
> > > >
> > > > Josh
> > > >
> > > >
> > > >
> > > > Joshua Parmenter | Engineering Lead, Apple Technologies
> > > >
> > > > T 248 777 
> > > > C 206 437 1551
> > > > F 248 616 1980
> > > > www.vectorform.com > > >
> > > > Vectorform
> > > > 2211 5th Ave Suite 201
> > > > Seattle, WA 98121 USA
> > > >
> > > > Think Tank. Lab. Studio.
> > > > We invent digital products and experiences.
> > > >
> > > > SEATTLE | DETROIT | NEW YORK | MUNICH | HYDERABAD
> > > > ___
> > > > 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
> > >
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Benjamin G via swift-evolution]

Ok, sorry for that answer that was really too quick. It seems that i really
didn't answer the rational for the "elementsEqual" function in the first
place which seems to be related to comparing sequences of different types,
so just ignore my last comment.

I do however wants to reiterate my encouragement to core language
developers to not get frightened to make deep source breaking changes if it
helps developers stay away from undefined behaviors (such as preventing
people from using first() or elementsEquals() on sets).


On Fri, Oct 13, 2017 at 7:08 PM, Benjamin G via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi, i'm not following this mailing for a long enough time, so i'm sorry if
> all this conversation already took place. It seems however pretty obvious
> to me what "ordered" and "unordered" means, and , knowing that collections
> have value semantics in swift, i would expect the regular "==" to take that
> difference into account, without having to resort to special functions..
> Same as i would expect a complex numbers struct to compare correctly the
> real and complex components, a vector compare correctly its dimension
> components, and a regular (unordered) set to work only in terms of unions,
> intersections and membership. Mostly because it seems to me that it's
> traditional mathematical definition of equality in those cases...
>
>
>
> On Fri, Oct 13, 2017 at 3:52 PM, Xiaodi Wu  wrote:
>
>> You’re welcome to bikeshed the entire API surface area of sequences and
>> collections, but you won’t be the first to explore this area. A number of
>> us looked into this area in the past few years and did not reach a
>> measurable improved result.
>>
>> Sequences can be ordered or unordered, single-pass or multi-pass, finite
>> or infinite, lazy or eager. Not all the combinations of these attributes
>> make sense, but many do. For each combination, a different subset of the
>> sequence algorithms are “useful.” As an example, “last” is not great for an
>> infinite sequence. It’s possibly also not what you want for a single-pass
>> sequence.
>>
>> Now, as to the problem discussed here. It’s an orthogonal problem to what
>> you are discussing because, whether or not you reorganize the protocols
>> entirely, there is still going to be confusion about how exactly
>> “elementsEqual” differs from “==“ even for an ordered sequence. The name is
>> clearly problematic in that respect. However, I would argue that the
>> behavior of the method isn’t “improper” and the behavior is not “badly
>> defined.”
>>
>>
>> On Fri, Oct 13, 2017 at 07:09 Benjamin G 
>> wrote:
>>
>>> +1 on both points. As for your solutions, i see 1/ as the best solution.
>>> Breaking source code that rely on badly defined, or improper behavior isn't
>>> "breaking".  You don't break something that's already half broken.
>>> As an app developer relying on swift on my day to day job and making a
>>> living of it, i want to emphasis this: I really don't mind if a language
>>> version change is making me look more carefully on some parts of my code
>>> that i probably had overlooked.
>>> Sure i may pester a bit when the code doesn't compile, but it sure is
>>> better than discovering the weird behavior of a badly defined protocol
>>> hierarchy in customer support.
>>>
>>>
>>> On Fri, Oct 13, 2017 at 6:57 AM, Kevin Nattinger via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 –∞

 1. I strongly object to the proposed name. It doesn't make it more
 clear to me what the method does, and is misleading at best. Among other
 issues, "lexicographical" is defined as alphabet order, and (1) this method
 applies to objects that are not Strings, and (2) this method's behavior
 isn't any more well-defined for Strings, so that name is even more of a lie
 than the original.

 2. This is really just a symptom of a bigger problem. The fact that two
 Sets can compare equal and yet return different results for that method
 (among too many others) is logically inconsistent and points to a much
 deeper issue with Set and Sequence. It is probably about 3 releases too
 late to get this straightened out properly, but I'll outline the real issue
 in case someone has an idea for fixing it.

 *The root of the problem is that Set conforms to Sequence, but Sequence
 doesn't require a well-defined order.* Since Set doesn't have a
 well-defined order, a significant portion of its interface is unspecified.
 The methods are implemented because they have to be, but they doesn't have
 well-defined or necessarily consistent results.

 A sequence is, by definition, ordered. That is reflected in the fact
 that over half the methods in the main Sequence definition* make no sense
 and are not well-defined unless there is a well-defined order to the
 sequence itself. What does it even mean to `dropFirst()` in a 

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

[Kevin Nattinger via swift-evolution]

> On Oct 13, 2017, at 10:01 AM, Michael Ilseman  wrote:
> 
> 
> 
>> On Oct 12, 2017, at 9:57 PM, Kevin Nattinger via swift-evolution 
>> > wrote:
>> 
>> –∞
>> 
>> 1. I strongly object to the proposed name. It doesn't make it more clear to 
>> me what the method does, and is misleading at best. Among other issues, 
>> "lexicographical" is defined as alphabet order, and (1) this method applies 
>> to objects that are not Strings, and (2) this method's behavior isn't any 
>> more well-defined for Strings, so that name is even more of a lie than the 
>> original.
>> 
> 
> FWIW, in the context of String, "lexicographical ordering” does not imply 
> human-written-language-alphabetical order at all, as there’s no universal 
> alphabetical ordering for human language. I.e., such a concrete notion for 
> Strings does not exist, not even theoretically. “Lexicographical” derives its 
> meaning from the mathematical usage[1] which uses that term as well as 
> “alphabet” without being restricted to human-written-language, in which it 
> means some total ordering over a finite set.
> 
> [1] https://en.wikipedia.org/wiki/Lexicographical_order 
> 
I see, apologies for the mistake. 
Regardless of the specific type of ordering, lexicographicallyEquals says to me 
that the objects should be sorted into lexicographical order and compared. 
Precisely the opposite of the proposal.

> 
>> 2. This is really just a symptom of a bigger problem. The fact that two Sets 
>> can compare equal and yet return different results for that method (among 
>> too many others) is logically inconsistent and points to a much deeper issue 
>> with Set and Sequence. It is probably about 3 releases too late to get this 
>> straightened out properly, but I'll outline the real issue in case someone 
>> has an idea for fixing it.
>> 
>> The root of the problem is that Set conforms to Sequence, but Sequence 
>> doesn't require a well-defined order. Since Set doesn't have a well-defined 
>> order, a significant portion of its interface is unspecified. The methods 
>> are implemented because they have to be, but they doesn't have well-defined 
>> or necessarily consistent results.
>> 
>> A sequence is, by definition, ordered. That is reflected in the fact that 
>> over half the methods in the main Sequence definition* make no sense and are 
>> not well-defined unless there is a well-defined order to the sequence 
>> itself. What does it even mean to `dropFirst()` in a Set? The fact that two 
>> objects that compare equal can give different results for a 100% 
>> deterministic function is illogical, nonsensical, and dangerous.
>> 
>> * 7/12 by my count, ignoring `_*` funcs but including the `var`
>> 
>> The current contents of Sequence can be cleanly divided into two groups; 
>> those that return SubSequence imply a specific ordering, and the rest do not.
>> 
>>  I think those should be/should have been two separate protocols:
>> 
>> public protocol Iterable {
>>   associatedtype Iterator: IteratorProtocol
>>   func map(...) -> [T] // Iterable where .Iterator.Element == T
>>   func filter(...) -> [Iterator.Element] // Iterable where .Iterator.Element 
>> == Self.Iterator.Element
>>   func forEach(...)
>>   func makeIterator() -> Iterator
>>   var underestimatedCount: Int { get }
>> }
>> 
>> public protocol Sequence: Iterable { // Maybe OrderedSequence just to make 
>> the well-defined-order requirement explicit
>>   associatedtype SubSequence
>>   func dropFirst(...)   -> SubSequence   // Sequence where .Iterator.Element 
>> == Self.Iterator.Element
>>   func dropLast(...)-> SubSequence   //" "
>>   func drop(while...)   -> SubSequence   //" "
>>   func prefix(...)  -> SubSequence   //" "
>>   func prefix(while...) -> SubSequence   //" "
>>   func suffix(...)  -> SubSequence   //" "
>>   func split(...where...)  -> [SubSequence] // Iterable where 
>> .Iterator.Element == (Sequence where .Iterator.Element == 
>> Self.Iterator.Element)
>> }
>> 
>> (The comments, of course, would be more sensible types once the ideas can 
>> actually be expressed in Swift)
>> 
>> Then unordered collections (Set and Dictionary) would just conform to 
>> Iterable and not Sequence, so ALL the methods on those classes would make 
>> logical sense and have well-defined behavior; no change would be needed for 
>> ordered collections.
>> 
>> Now, the practical matter. If this were Swift 1->2 or 2->3, I doubt there 
>> would be a significant issue with actually making this change. 
>> Unfortunately, we're well beyond that and making a change this deep is an 
>> enormous deal. So I see two ways forward.
>> 
>> 1. We could go ahead and make this separation. Although it's a potentially 
>> large breaking change, I would argue that because the methods are 
>> ill-defined anyway, the breakage is justified and a net benefit.

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

[Benjamin G via swift-evolution]

Hi, i'm not following this mailing for a long enough time, so i'm sorry if
all this conversation already took place. It seems however pretty obvious
to me what "ordered" and "unordered" means, and , knowing that collections
have value semantics in swift, i would expect the regular "==" to take that
difference into account, without having to resort to special functions..
Same as i would expect a complex numbers struct to compare correctly the
real and complex components, a vector compare correctly its dimension
components, and a regular (unordered) set to work only in terms of unions,
intersections and membership. Mostly because it seems to me that it's
traditional mathematical definition of equality in those cases...



On Fri, Oct 13, 2017 at 3:52 PM, Xiaodi Wu  wrote:

> You’re welcome to bikeshed the entire API surface area of sequences and
> collections, but you won’t be the first to explore this area. A number of
> us looked into this area in the past few years and did not reach a
> measurable improved result.
>
> Sequences can be ordered or unordered, single-pass or multi-pass, finite
> or infinite, lazy or eager. Not all the combinations of these attributes
> make sense, but many do. For each combination, a different subset of the
> sequence algorithms are “useful.” As an example, “last” is not great for an
> infinite sequence. It’s possibly also not what you want for a single-pass
> sequence.
>
> Now, as to the problem discussed here. It’s an orthogonal problem to what
> you are discussing because, whether or not you reorganize the protocols
> entirely, there is still going to be confusion about how exactly
> “elementsEqual” differs from “==“ even for an ordered sequence. The name is
> clearly problematic in that respect. However, I would argue that the
> behavior of the method isn’t “improper” and the behavior is not “badly
> defined.”
>
>
> On Fri, Oct 13, 2017 at 07:09 Benjamin G 
> wrote:
>
>> +1 on both points. As for your solutions, i see 1/ as the best solution.
>> Breaking source code that rely on badly defined, or improper behavior isn't
>> "breaking".  You don't break something that's already half broken.
>> As an app developer relying on swift on my day to day job and making a
>> living of it, i want to emphasis this: I really don't mind if a language
>> version change is making me look more carefully on some parts of my code
>> that i probably had overlooked.
>> Sure i may pester a bit when the code doesn't compile, but it sure is
>> better than discovering the weird behavior of a badly defined protocol
>> hierarchy in customer support.
>>
>>
>> On Fri, Oct 13, 2017 at 6:57 AM, Kevin Nattinger via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> –∞
>>>
>>> 1. I strongly object to the proposed name. It doesn't make it more clear
>>> to me what the method does, and is misleading at best. Among other issues,
>>> "lexicographical" is defined as alphabet order, and (1) this method applies
>>> to objects that are not Strings, and (2) this method's behavior isn't any
>>> more well-defined for Strings, so that name is even more of a lie than the
>>> original.
>>>
>>> 2. This is really just a symptom of a bigger problem. The fact that two
>>> Sets can compare equal and yet return different results for that method
>>> (among too many others) is logically inconsistent and points to a much
>>> deeper issue with Set and Sequence. It is probably about 3 releases too
>>> late to get this straightened out properly, but I'll outline the real issue
>>> in case someone has an idea for fixing it.
>>>
>>> *The root of the problem is that Set conforms to Sequence, but Sequence
>>> doesn't require a well-defined order.* Since Set doesn't have a
>>> well-defined order, a significant portion of its interface is unspecified.
>>> The methods are implemented because they have to be, but they doesn't have
>>> well-defined or necessarily consistent results.
>>>
>>> A sequence is, by definition, ordered. That is reflected in the fact
>>> that over half the methods in the main Sequence definition* make no sense
>>> and are not well-defined unless there is a well-defined order to the
>>> sequence itself. What does it even mean to `dropFirst()` in a Set? The fact
>>> that two objects that compare equal can give different results for a 100% 
>>> deterministic
>>> function is illogical, nonsensical, and dangerous.
>>>
>>> * 7/12 by my count, ignoring `_*` funcs but including the `var`
>>>
>>> The current contents of Sequence can be cleanly divided into two groups;
>>> those that return SubSequence imply a specific ordering, and the
>>> rest do not.
>>>
>>>  I think those should be/should have been two separate protocols:
>>>
>>> public protocol Iterable {
>>>   associatedtype Iterator: IteratorProtocol
>>>   func map(...) -> [T] // Iterable where .Iterator.Element == T
>>>   func filter(...) -> [Iterator.Element] // Iterable where
>>> .Iterator.Element == 

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

[Kevin Nattinger via swift-evolution]

> On Oct 13, 2017, at 6:52 AM, Xiaodi Wu  > wrote:
> 
> You’re welcome to bikeshed the entire API surface area of sequences and 
> collections, but you won’t be the first to explore this area. A number of us 
> looked into this area in the past few years and did not reach a measurable 
> improved result.

I don’t need or want to bikeshed the entire sequence and collection surface 
area, I just want to fix one clear and GLARING issue:

A Set is NOT a sequence.

Note that this goes for dictionaries and any other unordered “sequences" as 
well.

That was in an early draft of my original email, but I dropped it because I was 
afraid people would just stop reading and dismiss the idea out-of-hand without 
considering the problem or arguments. Apparently I should have at least put it 
at the bottom, so sorry if the root issue was unclear.

> Sequences can be ordered or unordered,

You seem to be confusing the English word “sequence” with the (current) Swift 
protocol “Sequence." A sequence is, by definition, ordered. Not enforcing that 
in a protocol does not override the English language, and as this entire thread 
demonstrates, causes issues further on down the line.

> single-pass or multi-pass, finite or infinite, lazy or eager. Not all the 
> combinations of these attributes make sense, but many do. For each 
> combination, a different subset of the sequence algorithms are “useful.” As 
> an example, “last” is not great for an infinite sequence.
> It’s possibly also not what you want for a single-pass sequence.

All of those actually are *sequences*, so it's essentially irrelevant to this 
discussion about not-sequences that conform to Sequence anyway.
 That said, because they are all sequences, there are still a few rational 
behaviors that make logical sense. An infinite loop or nil for infinite.last 
both make sense to me, and it IS what you want for a single-pass set, IMO it's 
a programmer error if the user calls last and they didn't want to burn the set.

> Now, as to the problem discussed here. It’s an orthogonal problem to what you 
> are discussing because, whether or not you reorganize the protocols entirely, 
> there is still going to be confusion about how exactly “elementsEqual” 
> differs from “==“ even for an ordered sequence. The name is clearly 
> problematic in that respect. However, I would argue that the behavior of the 
> method isn’t “improper” and the behavior is not “badly defined.”

Sure, `elementsEqual` isn't perfect, but it's a hell of a lot better than 
`lexicographicallyEquals`. And once you restrict Sequence to properly ordered 
sets, it makes a lot more sense. The problem is a function that compares 
elements "in the same order" when one or both of the sequences doesn't HAVE an 
order.


> 
> On Fri, Oct 13, 2017 at 07:09 Benjamin G  > wrote:
>> +1 on both points. As for your solutions, i see 1/ as the best solution. 
>> Breaking source code that rely on badly defined, or improper behavior isn't 
>> "breaking".  You don't break something that's already half broken.
>> As an app developer relying on swift on my day to day job and making a 
>> living of it, i want to emphasis this: I really don't mind if a language 
>> version change is making me look more carefully on some parts of my code 
>> that i probably had overlooked. 
>> Sure i may pester a bit when the code doesn't compile, but it sure is better 
>> than discovering the weird behavior of a badly defined protocol hierarchy in 
>> customer support.
>> 
>> 
>> On Fri, Oct 13, 2017 at 6:57 AM, Kevin Nattinger via swift-evolution 
>> > wrote:
>> –∞
>> 
>> 1. I strongly object to the proposed name. It doesn't make it more clear to 
>> me what the method does, and is misleading at best. Among other issues, 
>> "lexicographical" is defined as alphabet order, and (1) this method applies 
>> to objects that are not Strings, and (2) this method's behavior isn't any 
>> more well-defined for Strings, so that name is even more of a lie than the 
>> original.
>> 
>> 2. This is really just a symptom of a bigger problem. The fact that two Sets 
>> can compare equal and yet return different results for that method (among 
>> too many others) is logically inconsistent and points to a much deeper issue 
>> with Set and Sequence. It is probably about 3 releases too late to get this 
>> straightened out properly, but I'll outline the real issue in case someone 
>> has an idea for fixing it.
>> 
>> The root of the problem is that Set conforms to Sequence, but Sequence 
>> doesn't require a well-defined order. Since Set doesn't have a well-defined 
>> order, a significant portion of its interface is unspecified. The methods 
>> are implemented because they have to be, but they doesn't have well-defined 
>> or necessarily consistent results.
>> 
>> A sequence is, 

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

[Michael Ilseman via swift-evolution]

> On Oct 12, 2017, at 9:57 PM, Kevin Nattinger via swift-evolution 
>  wrote:
> 
> –∞
> 
> 1. I strongly object to the proposed name. It doesn't make it more clear to 
> me what the method does, and is misleading at best. Among other issues, 
> "lexicographical" is defined as alphabet order, and (1) this method applies 
> to objects that are not Strings, and (2) this method's behavior isn't any 
> more well-defined for Strings, so that name is even more of a lie than the 
> original.
> 

FWIW, in the context of String, "lexicographical ordering” does not imply 
human-written-language-alphabetical order at all, as there’s no universal 
alphabetical ordering for human language. I.e., such a concrete notion for 
Strings does not exist, not even theoretically. “Lexicographical” derives its 
meaning from the mathematical usage[1] which uses that term as well as 
“alphabet” without being restricted to human-written-language, in which it 
means some total ordering over a finite set.

[1] https://en.wikipedia.org/wiki/Lexicographical_order

> 2. This is really just a symptom of a bigger problem. The fact that two Sets 
> can compare equal and yet return different results for that method (among too 
> many others) is logically inconsistent and points to a much deeper issue with 
> Set and Sequence. It is probably about 3 releases too late to get this 
> straightened out properly, but I'll outline the real issue in case someone 
> has an idea for fixing it.
> 
> The root of the problem is that Set conforms to Sequence, but Sequence 
> doesn't require a well-defined order. Since Set doesn't have a well-defined 
> order, a significant portion of its interface is unspecified. The methods are 
> implemented because they have to be, but they doesn't have well-defined or 
> necessarily consistent results.
> 
> A sequence is, by definition, ordered. That is reflected in the fact that 
> over half the methods in the main Sequence definition* make no sense and are 
> not well-defined unless there is a well-defined order to the sequence itself. 
> What does it even mean to `dropFirst()` in a Set? The fact that two objects 
> that compare equal can give different results for a 100% deterministic 
> function is illogical, nonsensical, and dangerous.
> 
> * 7/12 by my count, ignoring `_*` funcs but including the `var`
> 
> The current contents of Sequence can be cleanly divided into two groups; 
> those that return SubSequence imply a specific ordering, and the rest do not.
> 
>  I think those should be/should have been two separate protocols:
> 
> public protocol Iterable {
>   associatedtype Iterator: IteratorProtocol
>   func map(...) -> [T] // Iterable where .Iterator.Element == T
>   func filter(...) -> [Iterator.Element] // Iterable where .Iterator.Element 
> == Self.Iterator.Element
>   func forEach(...)
>   func makeIterator() -> Iterator
>   var underestimatedCount: Int { get }
> }
> 
> public protocol Sequence: Iterable { // Maybe OrderedSequence just to make 
> the well-defined-order requirement explicit
>   associatedtype SubSequence
>   func dropFirst(...)   -> SubSequence   // Sequence where .Iterator.Element 
> == Self.Iterator.Element
>   func dropLast(...)-> SubSequence   //" "
>   func drop(while...)   -> SubSequence   //" "
>   func prefix(...)  -> SubSequence   //" "
>   func prefix(while...) -> SubSequence   //" "
>   func suffix(...)  -> SubSequence   //" "
>   func split(...where...)  -> [SubSequence] // Iterable where 
> .Iterator.Element == (Sequence where .Iterator.Element == 
> Self.Iterator.Element)
> }
> 
> (The comments, of course, would be more sensible types once the ideas can 
> actually be expressed in Swift)
> 
> Then unordered collections (Set and Dictionary) would just conform to 
> Iterable and not Sequence, so ALL the methods on those classes would make 
> logical sense and have well-defined behavior; no change would be needed for 
> ordered collections.
> 
> Now, the practical matter. If this were Swift 1->2 or 2->3, I doubt there 
> would be a significant issue with actually making this change. Unfortunately, 
> we're well beyond that and making a change this deep is an enormous deal. So 
> I see two ways forward.
> 
> 1. We could go ahead and make this separation. Although it's a potentially 
> large breaking change, I would argue that because the methods are ill-defined 
> anyway, the breakage is justified and a net benefit.
> 
> 2. We could try and think of a way to make the distinction between ordered 
> and unordered "sequences" in a less-breaking manner. Unfortunately, I don't 
> have a good suggestion for this, but if anyone has ideas, I'm all ears. Or 
> eyes, as the case may be.
> 
> 
>> On Oct 12, 2017, at 4:24 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> Rename Sequence.elementsEqual
>> 
>> Proposal: SE- 

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

[Nate Cook via swift-evolution]

> On Oct 13, 2017, at 9:59 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Fri, Oct 13, 2017 at 09:02 Adam Kemp  wrote:
>> Right, but if you do look it up you get a bunch of things talking about 
>> sorting words.
> 
> And that’s a perfect description of the behavior. It’s a lexicographical 
> comparison operation!
> 
>> How about pairwiseEqual?
> 
> A lexicographical comparison compares not merely pairwise, but in order from 
> the first item onwards, and stops at the first unequal pair. Proceeding in 
> order is key information, while stopping early on false is a nice-to-have. 
> There’s already a word for this, and it’s “lexicographical.” And the analogy 
> is universally understood: everyone has used a dictionary or index.

I think the argument is that in this case, we're not performing an ordering, 
and we aren't looking at the elements using an ordered comparison. This 
stretches the understood use of "lexicographic", so while I think it's probably 
okay, it isn't a slam dunk. To me, the biggest benefit of 
lexicographicallyMatches is that it's obtuse, so most people will need to look 
at the docs to get what it actually does, which we can improve to call out the 
unexpected behavior with Set and Dictionary.

Nate

>> 
>> --
>> Adam Kemp
>> 
>>> On Oct 13, 2017, at 5:17 AM, Xiaodi Wu  wrote:
>>> 
>>> “Lexicographical comparison” is a pretty standard term, and easy to Google. 
>>> We didn’t make it up for Swift :)
>>> 
>>> Since Swift names this protocol Sequence, something named 
>>> “Sequence.sequenceEqual” cannot distinguish this method from ==.
>>> 
>>> 
 On Fri, Oct 13, 2017 at 01:28 Adam Kemp  wrote:
 I agree that the proposed name is a poor choice. If we just focus on the 
 naming part, there is precedent in other languages for the name 
 “sequenceEqual”. I think that name makes it a bit clearer that the result 
 is whether the sequences match pair wise rather than whether they have the 
 same elements irrespective of order. I don’t think it entirely solves the 
 problem, but I like it a lot better than the proposed name.
 
 --
 Adam Kemp
 
> On Oct 12, 2017, at 9:57 PM, Kevin Nattinger via swift-evolution 
>  wrote:
> 
> –∞
> 
> 1. I strongly object to the proposed name. It doesn't make it more clear 
> to me what the method does, and is misleading at best. Among other 
> issues, "lexicographical" is defined as alphabet order, and (1) this 
> method applies to objects that are not Strings, and (2) this method's 
> behavior isn't any more well-defined for Strings, so that name is even 
> more of a lie than the original.
> 
> 2. This is really just a symptom of a bigger problem. The fact that two 
> Sets can compare equal and yet return different results for that method 
> (among too many others) is logically inconsistent and points to a much 
> deeper issue with Set and Sequence. It is probably about 3 releases too 
> late to get this straightened out properly, but I'll outline the real 
> issue in case someone has an idea for fixing it.
> 
> The root of the problem is that Set conforms to Sequence, but Sequence 
> doesn't require a well-defined order. Since Set doesn't have a 
> well-defined order, a significant portion of its interface is 
> unspecified. The methods are implemented because they have to be, but 
> they doesn't have well-defined or necessarily consistent results.
> 
> A sequence is, by definition, ordered. That is reflected in the fact that 
> over half the methods in the main Sequence definition* make no sense and 
> are not well-defined unless there is a well-defined order to the sequence 
> itself. What does it even mean to `dropFirst()` in a Set? The fact that 
> two objects that compare equal can give different results for a 100% 
> deterministic function is illogical, nonsensical, and dangerous.
> 
> * 7/12 by my count, ignoring `_*` funcs but including the `var`
> 
> The current contents of Sequence can be cleanly divided into two groups; 
> those that return SubSequence imply a specific ordering, and the rest do 
> not.
> 
>  I think those should be/should have been two separate protocols:
> 
> public protocol Iterable {
>   associatedtype Iterator: IteratorProtocol
>   func map(...) -> [T] // Iterable where .Iterator.Element == T
>   func filter(...) -> [Iterator.Element] // Iterable where 
> .Iterator.Element == Self.Iterator.Element
>   func forEach(...)
>   func makeIterator() -> Iterator
>   var underestimatedCount: Int { get }
> }
> 
> public protocol Sequence: Iterable { // Maybe OrderedSequence just to 
> make the well-defined-order requirement explicit
>   associatedtype SubSequence

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

[Adam Kemp via swift-evolution]

--
Adam Kemp

> On Oct 13, 2017, at 7:59 AM, Xiaodi Wu  wrote:
> 
>> On Fri, Oct 13, 2017 at 09:02 Adam Kemp  wrote:
>> Right, but if you do look it up you get a bunch of things talking about 
>> sorting words.
> 
> And that’s a perfect description of the behavior. It’s a lexicographical 
> comparison operation!

Is it? Are we always comparing words?

> 
>> How about pairwiseEqual?
> 
> A lexicographical comparison compares not merely pairwise, but in order from 
> the first item onwards, and stops at the first unequal pair. Proceeding in 
> order is key information, while stopping early on false is a nice-to-have. 
> There’s already a word for this, and it’s “lexicographical.” And the analogy 
> is universally understood: everyone has used a dictionary or index.

Clearly it’s not. You have several people telling you they don’t think it’s 
clear. You can argue that it’s technically correct if you want, but don’t try 
to tell us everyone understands it when it’s obvious that’s not true. 

> 
>> 
>> 
>> --
>> Adam Kemp
>> 
>>> On Oct 13, 2017, at 5:17 AM, Xiaodi Wu  wrote:
>>> 
>>> “Lexicographical comparison” is a pretty standard term, and easy to Google. 
>>> We didn’t make it up for Swift :)
>>> 
>>> Since Swift names this protocol Sequence, something named 
>>> “Sequence.sequenceEqual” cannot distinguish this method from ==.
>>> 
>>> 
 On Fri, Oct 13, 2017 at 01:28 Adam Kemp  wrote:
 I agree that the proposed name is a poor choice. If we just focus on the 
 naming part, there is precedent in other languages for the name 
 “sequenceEqual”. I think that name makes it a bit clearer that the result 
 is whether the sequences match pair wise rather than whether they have the 
 same elements irrespective of order. I don’t think it entirely solves the 
 problem, but I like it a lot better than the proposed name.
 
 --
 Adam Kemp
 
> On Oct 12, 2017, at 9:57 PM, Kevin Nattinger via swift-evolution 
>  wrote:
> 
> –∞
> 
> 1. I strongly object to the proposed name. It doesn't make it more clear 
> to me what the method does, and is misleading at best. Among other 
> issues, "lexicographical" is defined as alphabet order, and (1) this 
> method applies to objects that are not Strings, and (2) this method's 
> behavior isn't any more well-defined for Strings, so that name is even 
> more of a lie than the original.
> 
> 2. This is really just a symptom of a bigger problem. The fact that two 
> Sets can compare equal and yet return different results for that method 
> (among too many others) is logically inconsistent and points to a much 
> deeper issue with Set and Sequence. It is probably about 3 releases too 
> late to get this straightened out properly, but I'll outline the real 
> issue in case someone has an idea for fixing it.
> 
> The root of the problem is that Set conforms to Sequence, but Sequence 
> doesn't require a well-defined order. Since Set doesn't have a 
> well-defined order, a significant portion of its interface is 
> unspecified. The methods are implemented because they have to be, but 
> they doesn't have well-defined or necessarily consistent results.
> 
> A sequence is, by definition, ordered. That is reflected in the fact that 
> over half the methods in the main Sequence definition* make no sense and 
> are not well-defined unless there is a well-defined order to the sequence 
> itself. What does it even mean to `dropFirst()` in a Set? The fact that 
> two objects that compare equal can give different results for a 100% 
> deterministic function is illogical, nonsensical, and dangerous.
> 
> * 7/12 by my count, ignoring `_*` funcs but including the `var`
> 
> The current contents of Sequence can be cleanly divided into two groups; 
> those that return SubSequence imply a specific ordering, and the rest do 
> not.
> 
>  I think those should be/should have been two separate protocols:
> 
> public protocol Iterable {
>   associatedtype Iterator: IteratorProtocol
>   func map(...) -> [T] // Iterable where .Iterator.Element == T
>   func filter(...) -> [Iterator.Element] // Iterable where 
> .Iterator.Element == Self.Iterator.Element
>   func forEach(...)
>   func makeIterator() -> Iterator
>   var underestimatedCount: Int { get }
> }
> 
> public protocol Sequence: Iterable { // Maybe OrderedSequence just to 
> make the well-defined-order requirement explicit
>   associatedtype SubSequence
>   func dropFirst(...)   -> SubSequence   // Sequence where 
> .Iterator.Element == Self.Iterator.Element
>   func dropLast(...)-> SubSequence   //" "
>   func drop(while...)   -> SubSequence   //" "
>   func 

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

[Xiaodi Wu via swift-evolution]

On Fri, Oct 13, 2017 at 09:02 Adam Kemp  wrote:

> Right, but if you do look it up you get a bunch of things talking about
> sorting words.
>

And that’s a perfect description of the behavior. It’s a lexicographical
comparison operation!

How about pairwiseEqual?
>

A lexicographical comparison compares not merely pairwise, but in order
from the first item onwards, and stops at the first unequal pair.
Proceeding in order is key information, while stopping early on false is a
nice-to-have. There’s already a word for this, and it’s “lexicographical.”
And the analogy is universally understood: everyone has used a dictionary
or index.


>
> --
> Adam Kemp
>
> On Oct 13, 2017, at 5:17 AM, Xiaodi Wu  wrote:
>
> “Lexicographical comparison” is a pretty standard term, and easy to
> Google. We didn’t make it up for Swift :)
>
> Since Swift names this protocol Sequence, something named
> “Sequence.sequenceEqual” cannot distinguish this method from ==.
>
>
> On Fri, Oct 13, 2017 at 01:28 Adam Kemp  wrote:
>
>> I agree that the proposed name is a poor choice. If we just focus on the
>> naming part, there is precedent in other languages for the name
>> “sequenceEqual”. I think that name makes it a bit clearer that the result
>> is whether the sequences match pair wise rather than whether they have the
>> same elements irrespective of order. I don’t think it entirely solves the
>> problem, but I like it a lot better than the proposed name.
>>
>> --
>> Adam Kemp
>>
>> On Oct 12, 2017, at 9:57 PM, Kevin Nattinger via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> –∞
>>
>> 1. I strongly object to the proposed name. It doesn't make it more clear
>> to me what the method does, and is misleading at best. Among other issues,
>> "lexicographical" is defined as alphabet order, and (1) this method applies
>> to objects that are not Strings, and (2) this method's behavior isn't any
>> more well-defined for Strings, so that name is even more of a lie than the
>> original.
>>
>> 2. This is really just a symptom of a bigger problem. The fact that two
>> Sets can compare equal and yet return different results for that method
>> (among too many others) is logically inconsistent and points to a much
>> deeper issue with Set and Sequence. It is probably about 3 releases too
>> late to get this straightened out properly, but I'll outline the real issue
>> in case someone has an idea for fixing it.
>>
>> *The root of the problem is that Set conforms to Sequence, but Sequence
>> doesn't require a well-defined order.* Since Set doesn't have a
>> well-defined order, a significant portion of its interface is unspecified.
>> The methods are implemented because they have to be, but they doesn't have
>> well-defined or necessarily consistent results.
>>
>> A sequence is, by definition, ordered. That is reflected in the fact that
>> over half the methods in the main Sequence definition* make no sense and
>> are not well-defined unless there is a well-defined order to the sequence
>> itself. What does it even mean to `dropFirst()` in a Set? The fact that two
>> objects that compare equal can give different
>> results for a 100% deterministic function is illogical, nonsensical, and
>> dangerous.
>>
>> * 7/12 by my count, ignoring `_*` funcs but including the `var`
>>
>> The current contents of Sequence can be cleanly divided into two groups;
>> those that return SubSequence imply a specific ordering, and the
>> rest do not.
>>
>>  I think those should be/should have been two separate protocols:
>>
>> public protocol Iterable {
>>   associatedtype Iterator: IteratorProtocol
>>   func map(...) -> [T] // Iterable where .Iterator.Element == T
>>   func filter(...) -> [Iterator.Element] // Iterable where
>> .Iterator.Element == Self.Iterator.Element
>>   func forEach(...)
>>   func makeIterator() -> Iterator
>>   var underestimatedCount: Int { get }
>> }
>>
>> public protocol Sequence: Iterable { // Maybe OrderedSequence just to
>> make the well-defined-order requirement explicit
>>   associatedtype SubSequence
>>   func dropFirst(...)   -> SubSequence   // Sequence where
>> .Iterator.Element == Self.Iterator.Element
>>   func dropLast(...)-> SubSequence   //" "
>>   func drop(while...)   -> SubSequence   //" "
>>   func prefix(...)  -> SubSequence   //" "
>>   func prefix(while...) -> SubSequence   //" "
>>   func suffix(...)  -> SubSequence   //" "
>>   func split(...where...)  -> [SubSequence] // Iterable where
>> .Iterator.Element == (Sequence where .Iterator.Element ==
>> Self.Iterator.Element)
>> }
>>
>> (The comments, of course, would be more sensible types once the ideas can
>> actually be expressed in Swift)
>>
>> Then unordered collections (Set and Dictionary) would just conform to
>> Iterable and not Sequence, so ALL the methods on those classes would make
>> logical sense and have well-defined behavior; no change would be
>> needed 

Re: [swift-evolution] [Proposal] Random Unification

[Brent Royal-Gordon via swift-evolution]

> On Oct 11, 2017, at 10:21 AM, Cory Benfield via swift-evolution 
>  wrote:
> 
> This user will never swap away from the default, so the question is which 
> failure mode is preferable. I’d say it seems pretty obvious that “my program 
> is slow” is a better failure mode than “my program is vulnerable to data 
> exfiltration”.


Not only because "too slow" is safer than "too vulnerable", but also because 
"too slow" is something you can easily observe during development. Presumably, 
a web search for "swift randomIn slow" (or whatever) will then turn up blog 
posts and Stack Overflow answers explaining how to use a faster RNG.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adam Kemp via swift-evolution]

Right, but if you do look it up you get a bunch of things talking about sorting 
words.

How about pairwiseEqual?

--
Adam Kemp

> On Oct 13, 2017, at 5:17 AM, Xiaodi Wu  wrote:
> 
> “Lexicographical comparison” is a pretty standard term, and easy to Google. 
> We didn’t make it up for Swift :)
> 
> Since Swift names this protocol Sequence, something named 
> “Sequence.sequenceEqual” cannot distinguish this method from ==.
> 
> 
>> On Fri, Oct 13, 2017 at 01:28 Adam Kemp  wrote:
>> I agree that the proposed name is a poor choice. If we just focus on the 
>> naming part, there is precedent in other languages for the name 
>> “sequenceEqual”. I think that name makes it a bit clearer that the result is 
>> whether the sequences match pair wise rather than whether they have the same 
>> elements irrespective of order. I don’t think it entirely solves the 
>> problem, but I like it a lot better than the proposed name.
>> 
>> --
>> Adam Kemp
>> 
>>> On Oct 12, 2017, at 9:57 PM, Kevin Nattinger via swift-evolution 
>>>  wrote:
>>> 
>>> –∞
>>> 
>>> 1. I strongly object to the proposed name. It doesn't make it more clear to 
>>> me what the method does, and is misleading at best. Among other issues, 
>>> "lexicographical" is defined as alphabet order, and (1) this method applies 
>>> to objects that are not Strings, and (2) this method's behavior isn't any 
>>> more well-defined for Strings, so that name is even more of a lie than the 
>>> original.
>>> 
>>> 2. This is really just a symptom of a bigger problem. The fact that two 
>>> Sets can compare equal and yet return different results for that method 
>>> (among too many others) is logically inconsistent and points to a much 
>>> deeper issue with Set and Sequence. It is probably about 3 releases too 
>>> late to get this straightened out properly, but I'll outline the real issue 
>>> in case someone has an idea for fixing it.
>>> 
>>> The root of the problem is that Set conforms to Sequence, but Sequence 
>>> doesn't require a well-defined order. Since Set doesn't have a well-defined 
>>> order, a significant portion of its interface is unspecified. The methods 
>>> are implemented because they have to be, but they doesn't have well-defined 
>>> or necessarily consistent results.
>>> 
>>> A sequence is, by definition, ordered. That is reflected in the fact that 
>>> over half the methods in the main Sequence definition* make no sense and 
>>> are not well-defined unless there is a well-defined order to the sequence 
>>> itself. What does it even mean to `dropFirst()` in a Set? The fact that two 
>>> objects that compare equal can give different results for a 100% 
>>> deterministic function is illogical, nonsensical, and dangerous.
>>> 
>>> * 7/12 by my count, ignoring `_*` funcs but including the `var`
>>> 
>>> The current contents of Sequence can be cleanly divided into two groups; 
>>> those that return SubSequence imply a specific ordering, and the rest do 
>>> not.
>>> 
>>>  I think those should be/should have been two separate protocols:
>>> 
>>> public protocol Iterable {
>>>   associatedtype Iterator: IteratorProtocol
>>>   func map(...) -> [T] // Iterable where .Iterator.Element == T
>>>   func filter(...) -> [Iterator.Element] // Iterable where 
>>> .Iterator.Element == Self.Iterator.Element
>>>   func forEach(...)
>>>   func makeIterator() -> Iterator
>>>   var underestimatedCount: Int { get }
>>> }
>>> 
>>> public protocol Sequence: Iterable { // Maybe OrderedSequence just to make 
>>> the well-defined-order requirement explicit
>>>   associatedtype SubSequence
>>>   func dropFirst(...)   -> SubSequence   // Sequence where 
>>> .Iterator.Element == Self.Iterator.Element
>>>   func dropLast(...)-> SubSequence   //" "
>>>   func drop(while...)   -> SubSequence   //" "
>>>   func prefix(...)  -> SubSequence   //" "
>>>   func prefix(while...) -> SubSequence   //" "
>>>   func suffix(...)  -> SubSequence   //" "
>>>   func split(...where...)  -> [SubSequence] // Iterable where 
>>> .Iterator.Element == (Sequence where .Iterator.Element == 
>>> Self.Iterator.Element)
>>> }
>>> 
>>> (The comments, of course, would be more sensible types once the ideas can 
>>> actually be expressed in Swift)
>>> 
>>> Then unordered collections (Set and Dictionary) would just conform to 
>>> Iterable and not Sequence, so ALL the methods on those classes would make 
>>> logical sense and have well-defined behavior; no change would be needed for 
>>> ordered collections.
>>> 
>>> Now, the practical matter. If this were Swift 1->2 or 2->3, I doubt there 
>>> would be a significant issue with actually making this change. 
>>> Unfortunately, we're well beyond that and making a change this deep is an 
>>> enormous deal. So I see two ways forward.
>>> 
>>> 1. We could go ahead and make this separation. Although it's a potentially 
>>> large breaking change, I would argue that 

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

[Xiaodi Wu via swift-evolution]

You’re welcome to bikeshed the entire API surface area of sequences and
collections, but you won’t be the first to explore this area. A number of
us looked into this area in the past few years and did not reach a
measurable improved result.

Sequences can be ordered or unordered, single-pass or multi-pass, finite or
infinite, lazy or eager. Not all the combinations of these attributes make
sense, but many do. For each combination, a different subset of the
sequence algorithms are “useful.” As an example, “last” is not great for an
infinite sequence. It’s possibly also not what you want for a single-pass
sequence.

Now, as to the problem discussed here. It’s an orthogonal problem to what
you are discussing because, whether or not you reorganize the protocols
entirely, there is still going to be confusion about how exactly
“elementsEqual” differs from “==“ even for an ordered sequence. The name is
clearly problematic in that respect. However, I would argue that the
behavior of the method isn’t “improper” and the behavior is not “badly
defined.”


On Fri, Oct 13, 2017 at 07:09 Benjamin G 
wrote:

> +1 on both points. As for your solutions, i see 1/ as the best solution.
> Breaking source code that rely on badly defined, or improper behavior isn't
> "breaking".  You don't break something that's already half broken.
> As an app developer relying on swift on my day to day job and making a
> living of it, i want to emphasis this: I really don't mind if a language
> version change is making me look more carefully on some parts of my code
> that i probably had overlooked.
> Sure i may pester a bit when the code doesn't compile, but it sure is
> better than discovering the weird behavior of a badly defined protocol
> hierarchy in customer support.
>
>
> On Fri, Oct 13, 2017 at 6:57 AM, Kevin Nattinger via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> –∞
>>
>> 1. I strongly object to the proposed name. It doesn't make it more clear
>> to me what the method does, and is misleading at best. Among other issues,
>> "lexicographical" is defined as alphabet order, and (1) this method applies
>> to objects that are not Strings, and (2) this method's behavior isn't any
>> more well-defined for Strings, so that name is even more of a lie than the
>> original.
>>
>> 2. This is really just a symptom of a bigger problem. The fact that two
>> Sets can compare equal and yet return different results for that method
>> (among too many others) is logically inconsistent and points to a much
>> deeper issue with Set and Sequence. It is probably about 3 releases too
>> late to get this straightened out properly, but I'll outline the real issue
>> in case someone has an idea for fixing it.
>>
>> *The root of the problem is that Set conforms to Sequence, but Sequence
>> doesn't require a well-defined order.* Since Set doesn't have a
>> well-defined order, a significant portion of its interface is unspecified.
>> The methods are implemented because they have to be, but they doesn't have
>> well-defined or necessarily consistent results.
>>
>> A sequence is, by definition, ordered. That is reflected in the fact that
>> over half the methods in the main Sequence definition* make no sense and
>> are not well-defined unless there is a well-defined order to the sequence
>> itself. What does it even mean to `dropFirst()` in a Set? The fact that two
>> objects that compare equal can give different
>> results for a 100% deterministic function is illogical, nonsensical, and
>> dangerous.
>>
>> * 7/12 by my count, ignoring `_*` funcs but including the `var`
>>
>> The current contents of Sequence can be cleanly divided into two groups;
>> those that return SubSequence imply a specific ordering, and the
>> rest do not.
>>
>>  I think those should be/should have been two separate protocols:
>>
>> public protocol Iterable {
>>   associatedtype Iterator: IteratorProtocol
>>   func map(...) -> [T] // Iterable where .Iterator.Element == T
>>   func filter(...) -> [Iterator.Element] // Iterable where
>> .Iterator.Element == Self.Iterator.Element
>>   func forEach(...)
>>   func makeIterator() -> Iterator
>>   var underestimatedCount: Int { get }
>> }
>>
>> public protocol Sequence: Iterable { // Maybe OrderedSequence just to
>> make the well-defined-order requirement explicit
>>   associatedtype SubSequence
>>   func dropFirst(...)   -> SubSequence   // Sequence where
>> .Iterator.Element == Self.Iterator.Element
>>   func dropLast(...)-> SubSequence   //" "
>>   func drop(while...)   -> SubSequence   //" "
>>   func prefix(...)  -> SubSequence   //" "
>>   func prefix(while...) -> SubSequence   //" "
>>   func suffix(...)  -> SubSequence   //" "
>>   func split(...where...)  -> [SubSequence] // Iterable where
>> .Iterator.Element == (Sequence where .Iterator.Element ==
>> Self.Iterator.Element)
>> }
>>
>> (The comments, of course, would be more sensible types once the ideas can
>> 

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

[Kevin Nattinger via swift-evolution]

> 1. We could go ahead and make this separation. Although it's a potentially 
> large breaking change, I would argue that because the methods are ill-defined 
> anyway, the breakage is justified and a net benefit.
> 
> 2. We could try and think of a way to make the distinction between ordered 
> and unordered "sequences" in a less-breaking manner. Unfortunately, I don't 
> have a good suggestion for this, but if anyone has ideas, I'm all ears. Or 
> eyes, as the case may be.

It occurred to me, if we keep (and document) Sequence as unordered and move all 
the ordered methods to a new OrderedSequence, then we'd only be breaking truly 
broken code and we could even potentially offer a fix-it to change Sequence to 
OrderedSequence when we see the user using the ordered methods in places where 
we can see and change the generic definition. 

I think I'd still prefer Iterable/Sequence as far as naming, but this may be a 
more acceptable change, and I'd rather have this than no change. 


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

“Lexicographical comparison” is a pretty standard term, and easy to Google.
We didn’t make it up for Swift :)

Since Swift names this protocol Sequence, something named
“Sequence.sequenceEqual” cannot distinguish this method from ==.


On Fri, Oct 13, 2017 at 01:28 Adam Kemp  wrote:

> I agree that the proposed name is a poor choice. If we just focus on the
> naming part, there is precedent in other languages for the name
> “sequenceEqual”. I think that name makes it a bit clearer that the result
> is whether the sequences match pair wise rather than whether they have the
> same elements irrespective of order. I don’t think it entirely solves the
> problem, but I like it a lot better than the proposed name.
>
> --
> Adam Kemp
>
> On Oct 12, 2017, at 9:57 PM, Kevin Nattinger via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> –∞
>
> 1. I strongly object to the proposed name. It doesn't make it more clear
> to me what the method does, and is misleading at best. Among other issues,
> "lexicographical" is defined as alphabet order, and (1) this method applies
> to objects that are not Strings, and (2) this method's behavior isn't any
> more well-defined for Strings, so that name is even more of a lie than the
> original.
>
> 2. This is really just a symptom of a bigger problem. The fact that two
> Sets can compare equal and yet return different results for that method
> (among too many others) is logically inconsistent and points to a much
> deeper issue with Set and Sequence. It is probably about 3 releases too
> late to get this straightened out properly, but I'll outline the real issue
> in case someone has an idea for fixing it.
>
> *The root of the problem is that Set conforms to Sequence, but Sequence
> doesn't require a well-defined order.* Since Set doesn't have a
> well-defined order, a significant portion of its interface is unspecified.
> The methods are implemented because they have to be, but they doesn't have
> well-defined or necessarily consistent results.
>
> A sequence is, by definition, ordered. That is reflected in the fact that
> over half the methods in the main Sequence definition* make no sense and
> are not well-defined unless there is a well-defined order to the sequence
> itself. What does it even mean to `dropFirst()` in a Set? The fact that two
> objects that compare equal can give different
> results for a 100% deterministic function is illogical, nonsensical, and
> dangerous.
>
> * 7/12 by my count, ignoring `_*` funcs but including the `var`
>
> The current contents of Sequence can be cleanly divided into two groups;
> those that return SubSequence imply a specific ordering, and the
> rest do not.
>
>  I think those should be/should have been two separate protocols:
>
> public protocol Iterable {
>   associatedtype Iterator: IteratorProtocol
>   func map(...) -> [T] // Iterable where .Iterator.Element == T
>   func filter(...) -> [Iterator.Element] // Iterable where
> .Iterator.Element == Self.Iterator.Element
>   func forEach(...)
>   func makeIterator() -> Iterator
>   var underestimatedCount: Int { get }
> }
>
> public protocol Sequence: Iterable { // Maybe OrderedSequence just to
> make the well-defined-order requirement explicit
>   associatedtype SubSequence
>   func dropFirst(...)   -> SubSequence   // Sequence where
> .Iterator.Element == Self.Iterator.Element
>   func dropLast(...)-> SubSequence   //" "
>   func drop(while...)   -> SubSequence   //" "
>   func prefix(...)  -> SubSequence   //" "
>   func prefix(while...) -> SubSequence   //" "
>   func suffix(...)  -> SubSequence   //" "
>   func split(...where...)  -> [SubSequence] // Iterable where
> .Iterator.Element == (Sequence where .Iterator.Element ==
> Self.Iterator.Element)
> }
>
> (The comments, of course, would be more sensible types once the ideas can
> actually be expressed in Swift)
>
> Then unordered collections (Set and Dictionary) would just conform to
> Iterable and not Sequence, so ALL the methods on those classes would make
> logical sense and have well-defined behavior; no change would be
> needed for ordered collections.
>
> Now, the practical matter. If this were Swift 1->2 or 2->3, I doubt there
> would be a significant issue with actually making this change.
> Unfortunately, we're well beyond that and making a change this
> deep is an enormous deal. So I see two ways forward.
>
> 1. We could go ahead and make this separation. Although it's a potentially
> large breaking change, I would argue that because the methods are
> ill-defined anyway, the breakage is justified and a net benefit.
>
> 2. We could try and think of a way to make the distinction between ordered
> and unordered "sequences" in a less-breaking manner. Unfortunately, I don't
> have a good suggestion for this, but if anyone has ideas, I'm all ears. Or
> eyes, as the case may be.
>
>
> On Oct 12, 2017, at 4:24 PM, Xiaodi Wu via swift-evolution <
> 

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

[Benjamin G via swift-evolution]

+1 on both points. As for your solutions, i see 1/ as the best solution.
Breaking source code that rely on badly defined, or improper behavior isn't
"breaking".  You don't break something that's already half broken.
As an app developer relying on swift on my day to day job and making a
living of it, i want to emphasis this: I really don't mind if a language
version change is making me look more carefully on some parts of my code
that i probably had overlooked.
Sure i may pester a bit when the code doesn't compile, but it sure is
better than discovering the weird behavior of a badly defined protocol
hierarchy in customer support.


On Fri, Oct 13, 2017 at 6:57 AM, Kevin Nattinger via swift-evolution <
swift-evolution@swift.org> wrote:

> –∞
>
> 1. I strongly object to the proposed name. It doesn't make it more clear
> to me what the method does, and is misleading at best. Among other issues,
> "lexicographical" is defined as alphabet order, and (1) this method applies
> to objects that are not Strings, and (2) this method's behavior isn't any
> more well-defined for Strings, so that name is even more of a lie than the
> original.
>
> 2. This is really just a symptom of a bigger problem. The fact that two
> Sets can compare equal and yet return different results for that method
> (among too many others) is logically inconsistent and points to a much
> deeper issue with Set and Sequence. It is probably about 3 releases too
> late to get this straightened out properly, but I'll outline the real issue
> in case someone has an idea for fixing it.
>
> *The root of the problem is that Set conforms to Sequence, but Sequence
> doesn't require a well-defined order.* Since Set doesn't have a
> well-defined order, a significant portion of its interface is unspecified.
> The methods are implemented because they have to be, but they doesn't have
> well-defined or necessarily consistent results.
>
> A sequence is, by definition, ordered. That is reflected in the fact that
> over half the methods in the main Sequence definition* make no sense and
> are not well-defined unless there is a well-defined order to the sequence
> itself. What does it even mean to `dropFirst()` in a Set? The fact that two
> objects that compare equal can give different results for a 100% deterministic
> function is illogical, nonsensical, and dangerous.
>
> * 7/12 by my count, ignoring `_*` funcs but including the `var`
>
> The current contents of Sequence can be cleanly divided into two groups;
> those that return SubSequence imply a specific ordering, and the
> rest do not.
>
>  I think those should be/should have been two separate protocols:
>
> public protocol Iterable {
>   associatedtype Iterator: IteratorProtocol
>   func map(...) -> [T] // Iterable where .Iterator.Element == T
>   func filter(...) -> [Iterator.Element] // Iterable where
> .Iterator.Element == Self.Iterator.Element
>   func forEach(...)
>   func makeIterator() -> Iterator
>   var underestimatedCount: Int { get }
> }
>
> public protocol Sequence: Iterable { // Maybe OrderedSequence just to
> make the well-defined-order requirement explicit
>   associatedtype SubSequence
>   func dropFirst(...)   -> SubSequence   // Sequence where
> .Iterator.Element == Self.Iterator.Element
>   func dropLast(...)-> SubSequence   //" "
>   func drop(while...)   -> SubSequence   //" "
>   func prefix(...)  -> SubSequence   //" "
>   func prefix(while...) -> SubSequence   //" "
>   func suffix(...)  -> SubSequence   //" "
>   func split(...where...)  -> [SubSequence] // Iterable where
> .Iterator.Element == (Sequence where .Iterator.Element ==
> Self.Iterator.Element)
> }
>
> (The comments, of course, would be more sensible types once the ideas can
> actually be expressed in Swift)
>
> Then unordered collections (Set and Dictionary) would just conform to
> Iterable and not Sequence, so ALL the methods on those classes would make
> logical sense and have well-defined behavior; no change would be
> needed for ordered collections.
>
> Now, the practical matter. If this were Swift 1->2 or 2->3, I doubt there
> would be a significant issue with actually making this change.
> Unfortunately, we're well beyond that and making a change this
> deep is an enormous deal. So I see two ways forward.
>
> 1. We could go ahead and make this separation. Although it's a potentially
> large breaking change, I would argue that because the methods are
> ill-defined anyway, the breakage is justified and a net benefit.
>
> 2. We could try and think of a way to make the distinction between ordered
> and unordered "sequences" in a less-breaking manner. Unfortunately, I don't
> have a good suggestion for this, but if anyone has ideas, I'm all ears. Or
> eyes, as the case may be.
>
>
> On Oct 12, 2017, at 4:24 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Rename Sequence.elementsEqual
>
>- Proposal: SE-
>

Re: [swift-evolution] [Proposal] Random Unification

[Jonathan Hull via swift-evolution]

I like the earlier version we were talking about with both .random(in: 
ClosedRange<>) and .random(in:ClosedRange<>, using: RandomSource)

Thanks,
Jon

> On Oct 12, 2017, at 10:30 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> On Oct 11, 2017, at 10:02 AM, Kevin Nattinger via swift-evolution 
>  wrote:
>> 
>> IMO, if we have the extensions on Int(eger)/Float(ingPoint)/Array 
>> (RandomAccessSequence?), they should just be for convenience and with a sane 
>> default RNG*, and users that need more should just use methods on the RNGs 
>> directly.
> 
> No—that means code which uses these extremely convenient and attractive APIs 
> can never be testable and that there's no obvious way to go from "use the 
> default RNG" to "use this specific RNG".
> 
> Methods which use an RNG should take that RNG as a parameter—a parameter with 
> a default value of "the default RNG":
> 
>   init(randomIn range: CountableRange, from randomizer: Randomizer 
> = DefaultRandomizer.shared) {
>   …
>   }
> 
> This properly separates concerns between the Randomizer (which knows how to 
> return random data) and the type (which knows how to construct itself from 
> random data). It also makes it easy to use a randomized API you already knew 
> about with a RandomSource, and it creates a convention that users can apply 
> to their own designs for how to write testable and customizable randomized 
> code. We might even add a local refactoring which automatically adds a 
> Randomizer parameter to the function and passes it to randomized calls within 
> the body.
> 
> Don't add a global setter—you don't know what it might affect. Don't add a 
> bunch of calls constructing arbitrary types to the Randomizer (or whatever 
> it's called) protocol. Do it with dependency injection: pass the Randomizer 
> as a parameter.
> 
> -- 
> Brent Royal-Gordon
> Sent from my iPhone
> 
> ___
> 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

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

[Adam Kemp via swift-evolution]

I agree that the proposed name is a poor choice. If we just focus on the naming 
part, there is precedent in other languages for the name “sequenceEqual”. I 
think that name makes it a bit clearer that the result is whether the sequences 
match pair wise rather than whether they have the same elements irrespective of 
order. I don’t think it entirely solves the problem, but I like it a lot better 
than the proposed name.

--
Adam Kemp

> On Oct 12, 2017, at 9:57 PM, Kevin Nattinger via swift-evolution 
>  wrote:
> 
> –∞
> 
> 1. I strongly object to the proposed name. It doesn't make it more clear to 
> me what the method does, and is misleading at best. Among other issues, 
> "lexicographical" is defined as alphabet order, and (1) this method applies 
> to objects that are not Strings, and (2) this method's behavior isn't any 
> more well-defined for Strings, so that name is even more of a lie than the 
> original.
> 
> 2. This is really just a symptom of a bigger problem. The fact that two Sets 
> can compare equal and yet return different results for that method (among too 
> many others) is logically inconsistent and points to a much deeper issue with 
> Set and Sequence. It is probably about 3 releases too late to get this 
> straightened out properly, but I'll outline the real issue in case someone 
> has an idea for fixing it.
> 
> The root of the problem is that Set conforms to Sequence, but Sequence 
> doesn't require a well-defined order. Since Set doesn't have a well-defined 
> order, a significant portion of its interface is unspecified. The methods are 
> implemented because they have to be, but they doesn't have well-defined or 
> necessarily consistent results.
> 
> A sequence is, by definition, ordered. That is reflected in the fact that 
> over half the methods in the main Sequence definition* make no sense and are 
> not well-defined unless there is a well-defined order to the sequence itself. 
> What does it even mean to `dropFirst()` in a Set? The fact that two objects 
> that compare equal can give different results for a 100% deterministic 
> function is illogical, nonsensical, and dangerous.
> 
> * 7/12 by my count, ignoring `_*` funcs but including the `var`
> 
> The current contents of Sequence can be cleanly divided into two groups; 
> those that return SubSequence imply a specific ordering, and the rest do not.
> 
>  I think those should be/should have been two separate protocols:
> 
> public protocol Iterable {
>   associatedtype Iterator: IteratorProtocol
>   func map(...) -> [T] // Iterable where .Iterator.Element == T
>   func filter(...) -> [Iterator.Element] // Iterable where .Iterator.Element 
> == Self.Iterator.Element
>   func forEach(...)
>   func makeIterator() -> Iterator
>   var underestimatedCount: Int { get }
> }
> 
> public protocol Sequence: Iterable { // Maybe OrderedSequence just to make 
> the well-defined-order requirement explicit
>   associatedtype SubSequence
>   func dropFirst(...)   -> SubSequence   // Sequence where .Iterator.Element 
> == Self.Iterator.Element
>   func dropLast(...)-> SubSequence   //" "
>   func drop(while...)   -> SubSequence   //" "
>   func prefix(...)  -> SubSequence   //" "
>   func prefix(while...) -> SubSequence   //" "
>   func suffix(...)  -> SubSequence   //" "
>   func split(...where...)  -> [SubSequence] // Iterable where 
> .Iterator.Element == (Sequence where .Iterator.Element == 
> Self.Iterator.Element)
> }
> 
> (The comments, of course, would be more sensible types once the ideas can 
> actually be expressed in Swift)
> 
> Then unordered collections (Set and Dictionary) would just conform to 
> Iterable and not Sequence, so ALL the methods on those classes would make 
> logical sense and have well-defined behavior; no change would be needed for 
> ordered collections.
> 
> Now, the practical matter. If this were Swift 1->2 or 2->3, I doubt there 
> would be a significant issue with actually making this change. Unfortunately, 
> we're well beyond that and making a change this deep is an enormous deal. So 
> I see two ways forward.
> 
> 1. We could go ahead and make this separation. Although it's a potentially 
> large breaking change, I would argue that because the methods are ill-defined 
> anyway, the breakage is justified and a net benefit.
> 
> 2. We could try and think of a way to make the distinction between ordered 
> and unordered "sequences" in a less-breaking manner. Unfortunately, I don't 
> have a good suggestion for this, but if anyone has ideas, I'm all ears. Or 
> eyes, as the case may be.
> 
> 
>> On Oct 12, 2017, at 4:24 PM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> Rename Sequence.elementsEqual
>> 
>> Proposal: SE-
>> Authors: Xiaodi Wu
>> Review Manager: TBD
>> Status: Awaiting review
>> Introduction
>> 
>> The current behavior of Sequence.elementsEqual is potentially confusing to 
>> users given its