Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0127: Cleaning up stdlib Pointer and Buffer Routines

> On Jul 22, 2016, at 10:37 PM, Dmitri Gribenko via swift-evolution > wrote: > > On Fri, Jul 22, 2016 at 11:16 AM, Bob Wilson via swift-evolution > wrote: >> I have been looking at the parts of this proposal related to >> withUnsafe[Mutable]Pointer: >> > [...] > > I agree with everything tha

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

What if you wanted to filter such that you keep values less than some element that happens to be positive zero; might that keep around any negative zeros? Seems problematic. > On Jul 22, 2016, at 7:53 PM, Dave Abrahams wrote: > > >> on Fri Jul 22 2016, Xiaodi Wu wrote: >> >>> On Fri, Jul 22

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0127: Cleaning up stdlib Pointer and Buffer Routines

Ok, I'll update the proposal to withdraw the change of inout for withUnsafePointer. Under the discussion for the pull request, Bob mentioned possible removal of the multi-pointer variants (i.e. withUnsafe[Mutable]Pointers) - is this something that you'd agree on? If so, I'd add this to the pr

Re: [swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

There’s two case : 1. Bug from customer’s code 2. Bug from library/Framwork’s code If we fix the case 1(forbidden subclass/overriding), means the library/framework’s author must fix case 2 If want customer fix the case 2(allow subclass/overriding), means we can’t fix the case 1 What’s o

Re: [swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

There’s two case : 1. Bug from customer’s code 2. Bug from library/Framwork’s code If we fix the case 1(forbidden subclass/overriding), means the library/framework’s author must fix case 2 If want customer fix the case 2(allow subclass/overriding), means we can’t fix the case 1 What’s o

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> The point of this design is that `===` means identity and that `.same ` > also means identity. > > Since this is new territory I suppose we get to decide what identity > means for floating point. Should +0 and -0 have the same identity or > not? I’ll leave the answer to folks more knowledgable

Re: [swift-evolution] Type access level as the default for its members?

> On Jul 22, 2016, at 7:05 PM, Félix Cloutier wrote: > > The only point that judges the proposal on its merits would be the first one, > and I would personally be happy to have that discussion. https://github.com/apple/swift-evolution/pull/438 I think that battle is lost for now. > > Féli

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Xiaodi Wu wrote: > On Fri, Jul 22, 2016 at 10:04 PM, Matthew Johnson > wrote: > >> >> On Jul 22, 2016, at 9:57 PM, Dave Abrahams wrote: >> >> >> on Fri Jul 22 2016, Xiaodi Wu > > wrote: >> >> On Fri, Jul 22, 2016 at 9:46 PM, Dave Abrahams >>

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 10:04 PM, Matthew Johnson wrote: > > On Jul 22, 2016, at 9:57 PM, Dave Abrahams wrote: > > > on Fri Jul 22 2016, Xiaodi Wu > wrote: > > On Fri, Jul 22, 2016 at 9:46 PM, Dave Abrahams > wrote: > > > on Fri Jul 22 2016, Xiaodi Wu

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 9:57 PM, Dave Abrahams wrote: > > on Fri Jul 22 2016, Xiaodi Wu wrote: > > > On Fri, Jul 22, 2016 at 9:46 PM, Dave Abrahams > wrote: > > > >> > >> on Fri Jul 22 2016, Xiaodi Wu wrote: > >> > >> > On Fri, Jul 22, 2016 at 9:23 PM, Matthew Johnson < > matt...@anandabits.co

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:57 PM, Dave Abrahams wrote: > > > on Fri Jul 22 2016, Xiaodi Wu > wrote: > >> On Fri, Jul 22, 2016 at 9:46 PM, Dave Abrahams wrote: >> >>> >>> on Fri Jul 22 2016, Xiaodi Wu wrote: >>> On Fri, Jul 22, 2016 at 9:23 PM, Matthew Jo

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Xiaodi Wu wrote: > On Fri, Jul 22, 2016 at 9:46 PM, Dave Abrahams wrote: > >> >> on Fri Jul 22 2016, Xiaodi Wu wrote: >> >> > On Fri, Jul 22, 2016 at 9:23 PM, Matthew Johnson > > >> > wrote: >> > >> >> >> >> On Jul 22, 2016, at 9:17 PM, Xiaodi Wu wrote: >> >> >> >> On Fri,

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 9:53 PM, Dave Abrahams wrote: > > on Fri Jul 22 2016, Xiaodi Wu wrote: > > > On Fri, Jul 22, 2016 at 9:38 PM, wrote: > > > >> This seems reasonable to me. I don't see why `===` has to do a total > order > >> comparison when we already have another operator, `<=>`, that d

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Brent Royal-Gordon wrote: >> On Jul 22, 2016, at 7:23 PM, Dave Abrahams wrote: >> >> No, NSString's conformance to Identifiable (probably NSObject's, >> actually) would define `===` in terms of `isEqual()`. That's saying >> identity for these types is determined by `isEqua

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Xiaodi Wu wrote: > On Fri, Jul 22, 2016 at 9:38 PM, wrote: > >> This seems reasonable to me. I don't see why `===` has to do a total order >> comparison when we already have another operator, `<=>`, that does that. >> > > I take it back. It wouldn't solve the issue that gene

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 9:46 PM, Dave Abrahams wrote: > > on Fri Jul 22 2016, Xiaodi Wu wrote: > > > On Fri, Jul 22, 2016 at 9:23 PM, Matthew Johnson > > > wrote: > > > >> > >> On Jul 22, 2016, at 9:17 PM, Xiaodi Wu wrote: > >> > >> On Fri, Jul 22, 2016 at 9:15 PM, Matthew Johnson via swift-ev

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:46 PM, Dave Abrahams wrote: > > > on Fri Jul 22 2016, Xiaodi Wu wrote: > >> On Fri, Jul 22, 2016 at 9:23 PM, Matthew Johnson >> wrote: >> >>> >>> On Jul 22, 2016, at 9:17 PM, Xiaodi Wu wrote: >>> >>> On Fri, Jul 22, 2016 at 9:15 PM, Matthew Johnson via swift-evolu

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 7:23 PM, Dave Abrahams wrote: > > No, NSString's conformance to Identifiable (probably NSObject's, > actually) would define `===` in terms of `isEqual()`. That's saying > identity for these types is determined by `isEqual()`. So `===` no longer tests if both instances are

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Xiaodi Wu wrote: > On Fri, Jul 22, 2016 at 9:23 PM, Matthew Johnson > wrote: > >> >> On Jul 22, 2016, at 9:17 PM, Xiaodi Wu wrote: >> >> On Fri, Jul 22, 2016 at 9:15 PM, Matthew Johnson via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> >>> On Jul 22, 2016, a

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 9:38 PM, wrote: > This seems reasonable to me. I don't see why `===` has to do a total order > comparison when we already have another operator, `<=>`, that does that. > I take it back. It wouldn't solve the issue that generic `<` would still behave in surprising ways, wh

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Xiaodi Wu wrote: > On Fri, Jul 22, 2016 at 9:28 PM, Dave Abrahams wrote: > >> >> on Fri Jul 22 2016, Xiaodi Wu wrote: >> >> > On Fri, Jul 22, 2016 at 9:13 PM, Matthew Johnson > > >> > wrote: >> > >> >> >> >> On Jul 22, 2016, at 9:10 PM, Xiaodi Wu wrote: >> >> >> >> On Fri,

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

This seems reasonable to me. I don't see why `===` has to do a total order comparison when we already have another operator, `<=>`, that does that. > On Jul 22, 2016, at 7:35 PM, Xiaodi Wu wrote: > >> On Fri, Jul 22, 2016 at 9:28 PM, Dave Abrahams wrote: >> >> on Fri Jul 22 2016, Xiaodi Wu w

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 9:28 PM, Dave Abrahams wrote: > > on Fri Jul 22 2016, Xiaodi Wu wrote: > > > On Fri, Jul 22, 2016 at 9:13 PM, Matthew Johnson > > > wrote: > > > >> > >> On Jul 22, 2016, at 9:10 PM, Xiaodi Wu wrote: > >> > >> On Fri, Jul 22, 2016 at 9:08 PM, Matthew Johnson < > matt...@

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:26 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 9:23 PM, Matthew Johnson > wrote: > >> On Jul 22, 2016, at 9:17 PM, Xiaodi Wu > > wrote: >> >> On Fri, Jul 22, 2016 at 9:15 PM, Matthew Johnson via swift-evol

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Xiaodi Wu wrote: > On Fri, Jul 22, 2016 at 9:13 PM, Matthew Johnson > wrote: > >> >> On Jul 22, 2016, at 9:10 PM, Xiaodi Wu wrote: >> >> On Fri, Jul 22, 2016 at 9:08 PM, Matthew Johnson >> wrote: >> >>> >>> On Jul 22, 2016, at 9:04 PM, Xiaodi Wu wrote: >>> >>> On Fri, Jul

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:15 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 9:13 PM, Matthew Johnson > wrote: > >> On Jul 22, 2016, at 9:10 PM, Xiaodi Wu > > wrote: >> >> On Fri, Jul 22, 2016 at 9:08 PM, Matthew Johnson >

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 9:23 PM, Matthew Johnson wrote: > > On Jul 22, 2016, at 9:17 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 9:15 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> On Jul 22, 2016, at 9:04 PM, Dave Abrahams via swift-evolution < >> swi

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:24 PM, Dave Abrahams wrote: > > > on Fri Jul 22 2016, Matthew Johnson wrote: > >>> On Jul 22, 2016, at 9:04 PM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> >>> on Fri Jul 22 2016, Matthew Johnson >> > wrote: >>> >> >

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:17 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 9:15 PM, Matthew Johnson via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> On Jul 22, 2016, at 9:04 PM, Dave Abrahams via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >> on F

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:20 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 9:19 PM, Matthew Johnson > wrote: > >> On Jul 22, 2016, at 9:12 PM, Xiaodi Wu > > wrote: >> >> On Fri, Jul 22, 2016 at 9:09 PM, Jaden Geller >

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Matthew Johnson wrote: >> On Jul 22, 2016, at 9:04 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Fri Jul 22 2016, Matthew Johnson > > wrote: >> > On Jul 22, 2016, at 8:37 PM, Xiaodi Wu via swift-evolution mailto:s

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Brent Royal-Gordon wrote: >> On Jul 22, 2016, at 4:55 PM, Daniel Duan via swift-evolution >> wrote: >> >>> Well, it's still a very real question whether we ought to have the >>> additional API surface implied by areSame, or wether we should collapse >>> it with ===. >>> >

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 9:09 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Fri Jul 22 2016, Xiaodi Wu wrote: > > > On Fri, Jul 22, 2016 at 8:45 PM, Dave Abrahams > wrote: > > > >> > >> on Fri Jul 22 2016, Xiaodi Wu wrote: > >> > >> > On Fri, Jul 22, 2016 at 8:

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 9:19 PM, Matthew Johnson wrote: > > On Jul 22, 2016, at 9:12 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 9:09 PM, Jaden Geller > wrote: > >> 1. NaN != NaN and +0 == -0 [what the traditional comparison operators are >> constrained to do] >> 2. NaN == NaN, +0 == -0, a

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Xiaodi Wu wrote: > On Fri, Jul 22, 2016 at 8:45 PM, Dave Abrahams wrote: > >> >> on Fri Jul 22 2016, Xiaodi Wu wrote: >> >> > On Fri, Jul 22, 2016 at 8:20 PM, Dave Abrahams via swift-evolution < >> > swift-evolution@swift.org> wrote: >> > >> >> >> >> on Fri Jul 22 2016, Dan

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:12 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 9:09 PM, Jaden Geller > wrote: >> 1. NaN != NaN and +0 == -0 [what the traditional comparison operators are >> constrained to do] >> 2. NaN == NaN, +0 == -0, and the same number encoded d

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 9:15 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > On Jul 22, 2016, at 9:04 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > > > on Fri Jul 22 2016, Matthew Johnson wrote: > > On Jul 22, 2016, at 8:37 PM, Xiaod

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Jaden Geller wrote: > "The totalOrder predicate will order these cases, and it also > distinguishes between different representations of NaNs and between > the same decimal floating point number encoded in different ways." > - > [Wikipedia](https://en.wikipedia.org/wiki/IEEE

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:04 PM, Dave Abrahams via swift-evolution > wrote: > > > on Fri Jul 22 2016, Matthew Johnson > wrote: > >>> On Jul 22, 2016, at 8:37 PM, Xiaodi Wu via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> On Fri, Jul 2

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 9:13 PM, Matthew Johnson wrote: > > On Jul 22, 2016, at 9:10 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 9:08 PM, Matthew Johnson > wrote: > >> >> On Jul 22, 2016, at 9:04 PM, Xiaodi Wu wrote: >> >> On Fri, Jul 22, 2016 at 8:57 PM, Matthew Johnson >> wrote: >> >>

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Matthew Johnson wrote: >> On Jul 22, 2016, at 8:37 PM, Xiaodi Wu via swift-evolution >> wrote: >> >> On Fri, Jul 22, 2016 at 8:20 PM, Dave Abrahams via swift-evolution >> >> > >> wrote: >> >> on Fri Jul 22 2016, Daniel Duan wrote: >> >>

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 9:09 PM, Jaden Geller wrote: > 1. NaN != NaN and +0 == -0 [what the traditional comparison operators are > constrained to do] > 2. NaN == NaN, +0 == -0, and the same number encoded different ways > compare equal > 3. NaN == NaN, +0 != -0, and the same number encoded differ

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:10 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 9:08 PM, Matthew Johnson > wrote: > >> On Jul 22, 2016, at 9:04 PM, Xiaodi Wu > > wrote: >> >> On Fri, Jul 22, 2016 at 8:57 PM, Matthew Johnson >

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 9:08 PM, Matthew Johnson wrote: > > On Jul 22, 2016, at 9:04 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 8:57 PM, Matthew Johnson > wrote: > >> >> On Jul 22, 2016, at 8:54 PM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> On Fri, Jul 22,

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> 1. NaN != NaN and +0 == -0 [what the traditional comparison operators are > constrained to do] > 2. NaN == NaN, +0 == -0, and the same number encoded different ways compare > equal > 3. NaN == NaN, +0 != -0, and the same number encoded different ways compare > not equal Though it seems super

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:04 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 8:57 PM, Matthew Johnson > wrote: > >> On Jul 22, 2016, at 8:54 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> On Fri, Jul 22, 2016 at 8:52 PM, Jad

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:02 PM, Jaden Geller wrote: > >> Fair enough; the result of that will be, as Pyry noted above, that: >> >> ``` >> [-0.0, 1.0, .nan, 0.0].firstIndex(of: 0.0) //=> 3, not 0 >> ``` > > Well, ummm, that's unfortunate. This would be extremely surprising behavior, > and I cou

Re: [swift-evolution] Type access level as the default for its members?

The only point that judges the proposal on its merits would be the first one, and I would personally be happy to have that discussion. Félix > Le 22 juil. 2016 à 10:14:13, Jose Cheyo Jimenez via swift-evolution > a écrit : > > > > On Jul 22, 2016, at 3:34 AM, Eric-Paul Lecluse via swift-evo

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:00 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Jul 22, 2016, at 4:55 PM, Daniel Duan via swift-evolution >> wrote: >> >>> Well, it's still a very real question whether we ought to have the >>> additional API surface implied by areSame, or wether we sho

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 8:57 PM, Matthew Johnson wrote: > > On Jul 22, 2016, at 8:54 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Fri, Jul 22, 2016 at 8:52 PM, Jaden Geller via swift-evolution < > swift-evolution@swift.org> wrote: > >> "The totalOrder predicate w

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> If `===` is the new `areSame`, and `Hashable` is based on `===`, wouldn't > that mean that objects could only be hashed (and thus, be looked up in > Dictionary and Set) by identity? So, for instance, code like this: > > var set = Set() > > set.insert("test") > set.inse

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> Fair enough; the result of that will be, as Pyry noted above, that: > > ``` > [-0.0, 1.0, .nan, 0.0].firstIndex(of: 0.0) //=> 3, not 0 > ``` Well, ummm, that's unfortunate. This would be extremely surprising behavior, and I could easily see this causing bugs. Users would have to be very carefu

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 4:55 PM, Daniel Duan via swift-evolution > wrote: > >> Well, it's still a very real question whether we ought to have the >> additional API surface implied by areSame, or wether we should collapse >> it with ===. >> > > To spell this out (because I had to think about it f

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 8:54 PM, Xiaodi Wu via swift-evolution > wrote: > > On Fri, Jul 22, 2016 at 8:52 PM, Jaden Geller via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > "The totalOrder predicate will order these cases, and it also distinguishes > between different representat

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 8:52 PM, Jaden Geller via swift-evolution < swift-evolution@swift.org> wrote: > "The totalOrder predicate will order these cases, and it also > distinguishes between different representations of NaNs and between the > same decimal floating point number encoded in different

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

"The totalOrder predicate will order these cases, and it also distinguishes between different representations of NaNs and between the same decimal floating point number encoded in different ways." - [Wikipedia](https://en.wikipedia.org/wiki/IEEE_floating_point#Total-ordering_predicate) Sounds l

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 8:46 PM, Matthew Johnson wrote: > > On Jul 22, 2016, at 8:43 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Fri, Jul 22, 2016 at 8:42 PM, Jaden Geller > wrote: > >> For floating point, I'd hope that `a === b` if `(a <=> b) == .same` *but >>

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Jaden Geller wrote: >> For floating point, I'd hope that `a === b` if `(a <=> b) == .same` >> *but not iff*. This is to satisfy IEEE 754: "Comparisons shall >> ignore the sign of zero (so +0 = −0)". > > I don't see why both `(+0) === (-0)` and `(+0) <=> (-0)` can't return > `

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 8:45 PM, Dave Abrahams wrote: > > on Fri Jul 22 2016, Xiaodi Wu wrote: > > > On Fri, Jul 22, 2016 at 8:20 PM, Dave Abrahams via swift-evolution < > > swift-evolution@swift.org> wrote: > > > >> > >> on Fri Jul 22 2016, Daniel Duan wrote: > >> > >> >> On Jul 22, 2016, at 3

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Xiaodi Wu wrote: > On Fri, Jul 22, 2016 at 8:20 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> on Fri Jul 22 2016, Daniel Duan wrote: >> >> >> On Jul 22, 2016, at 3:00 PM, Dave Abrahams via swift-evolution < >> swift-evolution@swift.org>

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 8:43 PM, Xiaodi Wu via swift-evolution > wrote: > > On Fri, Jul 22, 2016 at 8:42 PM, Jaden Geller > wrote: >> For floating point, I'd hope that `a === b` if `(a <=> b) == .same` *but not >> iff*. This is to satisfy IEEE 754: "Comparisons sh

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 8:44 PM, Matthew Johnson wrote: > > On Jul 22, 2016, at 8:37 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Fri, Jul 22, 2016 at 8:20 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> on Fri Jul 22 2016, Dan

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 8:37 PM, Xiaodi Wu via swift-evolution > wrote: > > On Fri, Jul 22, 2016 at 8:20 PM, Dave Abrahams via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > on Fri Jul 22 2016, Daniel Duan wrote: > > >> On Jul 22, 2016, at 3:00 PM, Dave Abrahams via swift-evo

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 8:42 PM, Jaden Geller wrote: > For floating point, I'd hope that `a === b` if `(a <=> b) == .same` *but > not iff*. This is to satisfy IEEE 754: "Comparisons shall ignore the sign > of zero (so +0 = −0)". > > > I don't see why both `(+0) === (-0)` and `(+0) <=> (-0)` can't

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Jaden Geller wrote: > I really like this idea. I was initially opposed to changing the > behavior of `===`, but I think I'm for it now. Though there have been > quite a few situations where I specifically want reference identity, > in these situations I would not override the

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> For floating point, I'd hope that `a === b` if `(a <=> b) == .same` *but not > iff*. This is to satisfy IEEE 754: "Comparisons shall ignore the sign of zero > (so +0 = −0)". I don't see why both `(+0) === (-0)` and `(+0) <=> (-0)` can't return `true` and `.same`, respectively. This doesn't br

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 8:34 PM, Jaden Geller via swift-evolution > wrote: > > I really like this idea. I was initially opposed to changing the behavior of > `===`, but I think I'm for it now. Though there have been quite a few > situations where I specifically want reference identity, in these

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 8:20 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Fri Jul 22 2016, Daniel Duan wrote: > > >> On Jul 22, 2016, at 3:00 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> > >> > >> on Fri Jul 22 2016, Daniel D

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0127: Cleaning up stdlib Pointer and Buffer Routines

on Fri Jul 22 2016, Xiaodi Wu wrote: > On Fri, Jul 22, 2016 at 6:49 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> on Fri Jul 22 2016, Xiaodi Wu wrote: >> >> > On Fri, Jul 22, 2016 at 5:06 PM, Dave Abrahams via swift-evolution < >> > swift-evolution@swift.or

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

I really like this idea. I was initially opposed to changing the behavior of `===`, but I think I'm for it now. Though there have been quite a few situations where I specifically want reference identity, in these situations I would not override the `===` operator anyway; these objects were ident

Re: [swift-evolution] Add AnyHashable to the standard library

> On Jul 22, 2016, at 6:15 PM, Erica Sadun via swift-evolution > wrote: > > On Jul 22, 2016, at 4:34 PM, Dmitri Gribenko via swift-evolution > wrote: >> >> You can view the full proposal here: >> https://github.com/apple/swift-evolution/pull/458/files >> >> Dmitri > > The proposal looks so

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Daniel Duan wrote: >> On Jul 22, 2016, at 3:00 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Fri Jul 22 2016, Daniel Duan > > wrote: >> > On Jul 22, 2016, at 11:05 AM, Dave Abrahams via swift-evolution mailto:swif

Re: [swift-evolution] Returning nothing

On Jul 22, 2016, at 2:38 PM, James Dempsey via swift-evolution wrote: > > I think there might be some confusion since the Swift API Design Guidelines > session at WWDC 2016 mentions: > “One of the principles of this particular API Design Guidelines is that we > really want the use sites to rea

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0127: Cleaning up stdlib Pointer and Buffer Routines

On Fri, Jul 22, 2016 at 6:49 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Fri Jul 22 2016, Xiaodi Wu wrote: > > > On Fri, Jul 22, 2016 at 5:06 PM, Dave Abrahams via swift-evolution < > > swift-evolution@swift.org> wrote: > > > >> > >> on Fri Jul 22 2016, Bob Wi

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

I'm convinced. Let's make areSame === again! On Fri, Jul 22, 2016 at 18:55 Daniel Duan via swift-evolution < swift-evolution@swift.org> wrote: > On Jul 22, 2016, at 3:00 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > > > on Fri Jul 22 2016, Daniel Duan wrote: > > O

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

Sorry, yeah, that's what I meant to ask. I can't see how it would make anything unworkable, but I agree that it might not be very useful. On Fri, Jul 22, 2016 at 18:50 Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Fri Jul 22 2016, Xiaodi Wu wrote: > > > On Fri, Jul

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 3:00 PM, Dave Abrahams via swift-evolution > wrote: > > > on Fri Jul 22 2016, Daniel Duan > wrote: > >>> On Jul 22, 2016, at 11:05 AM, Dave Abrahams via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> >>> on Thu

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0127: Cleaning up stdlib Pointer and Buffer Routines

on Fri Jul 22 2016, Xiaodi Wu wrote: > On Fri, Jul 22, 2016 at 5:06 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> on Fri Jul 22 2016, Bob Wilson wrote: >> >> > It is not so clear what to do about SR-1956. (Charlie and I had some >> > comments on this in htt

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Xiaodi Wu wrote: > On Fri, Jul 22, 2016 at 5:48 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> on Fri Jul 22 2016, Xiaodi Wu wrote: >> >> > On Fri, Jul 22, 2016 at 3:54 PM, Dave Abrahams >> wrote: >> > >> >> >> >> on Fri Jul 22 2016, Xia

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Matthew Johnson wrote: >> On Jul 22, 2016, at 4:47 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Fri Jul 22 2016, Tony Allevato > >> > > >> wrote: >> >>> I like a lot of this, but the changes to Equatable are where I get stu

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Tony Allevato wrote: > On Fri, Jul 22, 2016 at 2:52 PM Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> on Fri Jul 22 2016, Tony Allevato wrote: >> >> > I like a lot of this, but the changes to Equatable are where I get stuck. >> > What are the

Re: [swift-evolution] [Pitch] separate syntax of class inheritance and protocol conformance

On Fri, Jul 22, 2016 at 6:23 PM, Boris Wang via swift-evolution < swift-evolution@swift.org> wrote: > why? > > I think it's just because subclass, protocol are different design patterns > . If you are doing the designing, you already know this information; moreover, you're required to use `overr

[swift-evolution] [Pitch] separate syntax of class inheritance and protocol conformance

why? I think it's just because subclass, protocol are different design patterns . same question: why we need man toilet and women toilet? it's culture ,it's civilization 2016年7月22日星期五，Brandon Knope via swift-evolution > 写道： > I guess my question comes down to this: > > Is this a change

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 6:13 PM, Stephen Canon wrote: > On Jul 22, 2016, at 6:55 PM, Matthew Johnson > wrote: > > > On Jul 22, 2016, at 5:50 PM, Stephen Canon wrote: > > On Jul 22, 2016, at 6:34 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > > > Sorry if it wasn

Re: [swift-evolution] Add AnyHashable to the standard library

> On Jul 22, 2016, at 4:34 PM, Dmitri Gribenko via swift-evolution > wrote: > > You can view the full proposal here: > https://github.com/apple/swift-evolution/pull/458/files > > Dmitri > The proposal looks solid. I would be in favor. -- E ___ s

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 6:55 PM, Matthew Johnson wrote: > >> On Jul 22, 2016, at 5:50 PM, Stephen Canon > > wrote: >> >>> On Jul 22, 2016, at 6:34 PM, Matthew Johnson via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> Sorry if it wasn’t clear. I’m

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 5:48 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Fri Jul 22 2016, Xiaodi Wu wrote: > > > On Fri, Jul 22, 2016 at 3:54 PM, Dave Abrahams > wrote: > > > >> > >> on Fri Jul 22 2016, Xiaodi Wu wrote: > >> > >> > On Fri, Jul 22, 2016 at 1:

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 5:50 PM, Stephen Canon wrote: > >> On Jul 22, 2016, at 6:34 PM, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Sorry if it wasn’t clear. I’m not suggesting taking that away. I’m asking >> whether we have considered defining `==`

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Fri Jul 22 2016, Xiaodi Wu wrote: > On Fri, Jul 22, 2016 at 3:54 PM, Dave Abrahams wrote: > >> >> on Fri Jul 22 2016, Xiaodi Wu wrote: >> >> > On Fri, Jul 22, 2016 at 1:05 PM, Dave Abrahams via swift-evolution < >> > swift-evolution@swift.org> wrote: >> > >> >> >> >> on Thu Jul 21 2016, Dua

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 5:41 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 5:34 PM, Matthew Johnson > wrote: > >> On Jul 22, 2016, at 5:29 PM, Xiaodi Wu > > wrote: >> >> On Fri, Jul 22, 2016 at 5:17 PM, Matthew Johnson via swift-evol

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 6:34 PM, Matthew Johnson via swift-evolution > wrote: > > Sorry if it wasn’t clear. I’m not suggesting taking that away. I’m asking > whether we have considered defining `==` on floating point types to be the > equivalence relation that is proposed for `areSame` and giv

Re: [swift-evolution] [Pitch] Unify joined(separator:) and flatten()

Here's a proposal draft. Comments welcome: https://gist.github.com/jtbandes/7978dc1848f7c37eeaa8e9aba27c7325 On Fri, Jul 22, 2016 at 2:51 PM, Ben Rimmington wrote: > > > On 22 Jul 2016, at 20:43, Jacob Bandes-Storch > wrote: > > > >> On Fri, Jul 22, 2016 at 8:35 AM, Ben Rimmington > wrote: >

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 5:34 PM, Matthew Johnson wrote: > > On Jul 22, 2016, at 5:29 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 5:17 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> On Jul 22, 2016, at 4:47 PM, Dave Abrahams via swift-evolution < >> swi

Re: [swift-evolution] [Pitch] separate syntax of class inheritance and protocol conformance

It's probably too late by now, but I've always enjoyed C#'s naming convention of having interfaces (C# protocols) names start with capitale I: IEquatable, IComparable You get used to it and it's a nice way of avoiding name clashes between classes and protocols, which we currently handle in Swif

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 3:54 PM, Dave Abrahams wrote: > > on Fri Jul 22 2016, Xiaodi Wu wrote: > > > On Fri, Jul 22, 2016 at 1:05 PM, Dave Abrahams via swift-evolution < > > swift-evolution@swift.org> wrote: > > > >> > >> on Thu Jul 21 2016, Duan wrote: > >> > >> > Great proposal. I want to sec

Re: [swift-evolution] Add AnyHashable to the standard library

You can view the full proposal here: https://github.com/apple/swift-evolution/pull/458/files Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j*/ ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evoluti

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 5:29 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 5:17 PM, Matthew Johnson via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> On Jul 22, 2016, at 4:47 PM, Dave Abrahams via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >> on F

[swift-evolution] Add AnyHashable to the standard library

Hi, The implementation of SE-0116 "Import Objective-C id as Swift Any type" requires a type-erased container for hashable values. We are proposing to add such a type-erased container under the name AnyHashable to the standard library. This proposal is additive, source-breaking changes are discus

Re: [swift-evolution] [Review] SE-0129: Package Manager Test Naming Conventions

>* What is your evaluation of the proposal? I really like this proposal as it reduces the surprise factor while continuing to promote convention over configuration. It also mirrors the way people are often would like to name their test modules. >* Is the problem being addressed signifi

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

On Fri, Jul 22, 2016 at 5:17 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > On Jul 22, 2016, at 4:47 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > > > on Fri Jul 22 2016, Tony Allevato wrote: > > I like a lot of this, but the change

  1   2   3   >