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

2017-10-13 Thread 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

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

2017-10-13 Thread 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

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

2017-10-13 Thread 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

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

2017-10-13 Thread 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,

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

2017-10-13 Thread 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 >

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

2017-10-13 Thread 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

Re: [swift-evolution] commas optional

2017-10-13 Thread 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

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

2017-10-13 Thread 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

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

2017-10-13 Thread 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

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

2017-10-13 Thread 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

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

2017-10-13 Thread 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

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

2017-10-13 Thread 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(_:) /

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

2017-10-13 Thread 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. >

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

2017-10-13 Thread 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) { ...

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

2017-10-13 Thread 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

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

2017-10-13 Thread 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 >

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

2017-10-13 Thread 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

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

2017-10-13 Thread 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

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

2017-10-13 Thread 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

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

2017-10-13 Thread 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 >>>

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

2017-10-13 Thread 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

Re: [swift-evolution] commas optional

2017-10-13 Thread 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

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

2017-10-13 Thread 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

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

2017-10-13 Thread 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

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

2017-10-13 Thread 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

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

2017-10-13 Thread 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

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

2017-10-13 Thread 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

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

2017-10-13 Thread 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

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

2017-10-13 Thread 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

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

2017-10-13 Thread 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

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

2017-10-13 Thread 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

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

2017-10-13 Thread 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

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

2017-10-13 Thread 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

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

2017-10-13 Thread 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 >

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

2017-10-13 Thread 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

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

2017-10-13 Thread 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

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

2017-10-13 Thread 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,

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

2017-10-13 Thread 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