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

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

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

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

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

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

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

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: >>>

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

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

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

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

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: >

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: >>>

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

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

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

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: >

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:

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: >> >>>

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:

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

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:

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,

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

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

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 < >> >

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

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." > - >

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

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 >> >>

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

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

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 >>

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,

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: > >>

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") >

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

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

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 > > wrote: > "The totalOrder predicate will order these cases,

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

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

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

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: > >> > >> >>

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

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: > >>

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)`

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

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

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 <

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

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: >>

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

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 >

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: > > > >> >

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

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

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 >>>

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

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

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 > >> > > >>

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

[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

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

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

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 >>>

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

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 >> > wrote: >> >> Sorry if it wasn’t clear. I’m not suggesting taking that away. I’m

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 < >> >

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:

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

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,

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

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

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

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] 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

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

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

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

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 scenarios where areSame

Re: [swift-evolution] [Revision] [Pitch] Rename `T.Type`

Where do these double generics come from? Never saw them... > On 22 Jul 2016, at 17:54, Anton Zhilin wrote: > > 2016-07-22 18:51 GMT+03:00 David Hart : >> Isn't the solution to a lot of these issues allowing explicit generalization >> instead of this

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

> 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 stuck.

Re: [swift-evolution] [Proposal] Change some collection iterators to use custom types instead of IndexIterator

(thumbs up) On Fri, Jul 22, 2016 at 4:35 PM, Michael Gottesman via swift-evolution < swift-evolution@swift.org> wrote: > Hello everyone! > > Iterators are very important for performance since we use them for for > loops. By default collections if they do not provide a custom iterator use >

Re: [swift-evolution] [Proposal] Move public AutoreleasingUnsafeMutablePointer API from StdlibCore -> Objective C Overlay

on Fri Jul 22 2016, Michael Gottesman wrote: >> On Jul 22, 2016, at 11:42 AM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Fri Jul 22 2016, Ben Rimmington > >> > >

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

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 https://github.com/apple/swift-evolution/pull/437 > .) Jordan raised > the objection

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

on Fri Jul 22 2016, Daniel Duan wrote: >> On Jul 22, 2016, at 11:05 AM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Thu Jul 21 2016, Duan > >> > > >> wrote: >> >>>

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

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 scenarios where areSame is useful *outside* the context of the > proposed new Comparable interface? > > I ask because changing the

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

> On 22 Jul 2016, at 20:43, Jacob Bandes-Storch wrote: > >> On Fri, Jul 22, 2016 at 8:35 AM, Ben Rimmington >> wrote: >> >>> On 22 Jul 2016, at 02:46, Jacob Bandes-Storch wrote: >>> >>> In the swift-lang Slack channel, a few of us were discussing

Re: [swift-evolution] Returning nothing

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 read grammatically.” and continues with a number of examples. and the current Swift

[swift-evolution] [Proposal] Change some collection iterators to use custom types instead of IndexIterator

Hello everyone! Iterators are very important for performance since we use them for for loops. By default collections if they do not provide a custom iterator use IndexingIterator as an iterator. IndexingIterator, while only supporting forward movement, is based on indices which possess the

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

on Fri Jul 22 2016, Xiaodi Wu wrote: > On Fri, Jul 22, 2016 at 2:26 PM, Pyry Jahkola via swift-evolution < > swift-evolution@swift.org> wrote: > >> I agree with Tony that we should still keep == and != as part of >> Equatable, and<, <=, >, and >= as part of Comparable, while offering >> default

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

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 second that areSame may mislead user to >> >

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

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 that Bob said, and I would like to comment on this part: >

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

> On Jul 22, 2016, at 11:05 AM, Dave Abrahams via swift-evolution > wrote: > > > on Thu Jul 21 2016, Duan > wrote: > >> Great proposal. I want to second that areSame may mislead user to >> think this

[swift-evolution] [Review] SE-0130: Replace repeating Character and UnicodeScalar forms of String.init

Hello Swift community, The review of "SE-0130: Replace repeating Character and UnicodeScalar forms of String.init" begins now and runs through July 24. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0130-string-initializers-cleanup.md

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

Xiaodi Wu wrote: > I just assumed that the core team's vision was that this would be addressed > by a domain-specific floating point `areSame(a: Self, b: Self) -> Bool { > return (a == 0 && b == 0) || (a <=> b) == .same }`. This is a valid > equivalence relation afaik. I guess so, but it's a

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

On Fri, Jul 22, 2016 at 8:35 AM, Ben Rimmington wrote: > > > On 22 Jul 2016, at 02:46, Jacob Bandes-Storch wrote: > > > > In the swift-lang Slack channel, a few of us were discussing > joined(separator:) and realized that flatten() does almost exactly the same > thing. >

  1   2   >