Re: [swift-evolution] Enums and Source Compatibility

> On 6 Sep 2017, at 4:35 pm, David Hart wrote: > > Hi Jordan, > > I like this new direction. But I have Rod’s inverse question: have you > considered only having the nonexhaustive keyword? Similar to how non-final > doesn't exist because its opposite is the default behaviour. That would also

Re: [swift-evolution] Enums and Source Compatibility

> On 6 Sep 2017, at 2:31 pm, Charlie Monroe wrote: >> On Sep 6, 2017, at 5:44 AM, Rod Brown via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> I think what you’re really asking for here is the “future” case mentioned in >> the Alternatives Considered section. I think that Jorda

Re: [swift-evolution] Enums and Source Compatibility

Hi Jordan, I like this new direction. But I have Rod’s inverse question: have you considered only having the nonexhaustive keyword? Similar to how non-final doesn't exist because its opposite is the default behaviour. That would also free us from searching for a good pair of keywords and only f

Re: [swift-evolution] Enums and Source Compatibility

> On Sep 6, 2017, at 5:44 AM, Rod Brown via swift-evolution > wrote: > >> >> On 6 Sep 2017, at 12:05 pm, Jarod Long via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> From the perspective of primarily an app developer rather than library >> author, I'm not a big fan of t

Re: [swift-evolution] Enums and Source Compatibility

> On 6 Sep 2017, at 12:05 pm, Jarod Long via swift-evolution > wrote: > > From the perspective of primarily an app developer rather than library > author, I'm not a big fan of this change. I find myself in the "unhappy with > the loss of compiler warnings" camp -- if I'm switching over every

Re: [swift-evolution] [Concurrency] async/await + actors

OK, I've been watching this thing for a couple weeks. I've done a lot of GCD network code. Invariably my completion method starts with dispatch_async(queue_want_to_handle_this_on,) Replying on the same queue would be nice I guess, only often all I need to do is update the UI in the comple

Re: [swift-evolution] Enums and Source Compatibility

>From the perspective of primarily an app developer rather than library author, >I'm not a big fan of this change. I find myself in the "unhappy with the loss >of compiler warnings" camp -- if I'm switching over every case of an enum, >then I almost certainly want to be notified that a new case

Re: [swift-evolution] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

> On Sep 5, 2017, at 6:28 PM, Taylor Swift wrote: > >> >> UMRP (raw pointer): >> --- func initializeMemory(as:at:(=0)count:(1)to:) >> +++ func initializeMemory(as:repeating:count:) // remove default count >> >> still extremely suspicious of this but i’m willing to compromise. also there >> s

Re: [swift-evolution] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

On Tue, Sep 5, 2017 at 5:36 PM, Andrew Trick wrote: > >>> In the new raw initializeMemory methods, Xiaodi and I agreed to make >>> it more clear that the offset is in terms of `self` rather than >>> `from`, and to further reduce ambiguity by forcing manual stride >>> computation and using an expl

Re: [swift-evolution] Enums and Source Compatibility

Hi Jordan, Upon further reflection, I’m going to withdraw my concerns about the defaulting and I think it’s the right solution after all. This is due to several thoughts I had rolling it around my head: 1. In a private project, you would expect all cases to be exhaustive, as this is guaranteed

Re: [swift-evolution] [Concurrency] async/await + actors

> On Sep 5, 2017, at 5:29 PM, Elliott Harris via swift-evolution > wrote: > >> >> On Sep 4, 2017, at 11:40 AM, Pierre Habouzit via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Sep 4, 2017, at 10:36 AM, Chris Lattner via swift-evolution >>> mailto:swift-evolution@swi

Re: [swift-evolution] Enums and Source Compatibility

Ah yes, my eye skipped that alternative for some reason! Sorry. I’d be concerned that avoiding a default is a fix for a compatibility problem, not a language design decision. If we look back in 5 years and say “why do we need to keep writing nonexhaustive everywhere?”, we’ll have to say “there w

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

I take issue with the fact that this problem is no different from accidentally gaining the default inheritance of *any* member required by a protocol and implemented in an extension of that protocol. The fact that in this case conformance is synthesized by the compiler instead of written in sour

Re: [swift-evolution] Enums and Source Compatibility

It's in the "Alternatives Considered" section. :-) That was my desired design when we started, but feedback convinced me that the break from Swift 4 mode would be too drastic. The same valid code would have a different meaning whether you were writing Swift 4 or Swift 5. Jordan > On Sep 5, 20

[swift-evolution] Re: Enums and Source Compatibility

Hi Jordan, I’m not sure how much bearing on this my comment will have. Have you considered having only “exhaustive” as a keyword, and make the default non-exhaustive? It seems that “exhaustive" would be the rarer case, as it promises a lot more about compatibility (much like there is no such th

Re: [swift-evolution] [Concurrency] async/await + actors

> On Sep 4, 2017, at 11:40 AM, Pierre Habouzit via swift-evolution > wrote: > >> On Sep 4, 2017, at 10:36 AM, Chris Lattner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> On Sep 3, 2017, at 12:44 PM, Pierre Habouzit > > wrote: >>> My cur

Re: [swift-evolution] Enums and Source Compatibility

I've taken everyone's feedback into consideration and written this up as a proposal: https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/-non-exhaustive-enums.md

Re: [swift-evolution] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

> > In the new raw initializeMemory methods, Xiaodi and I agreed to make > it more clear that the offset is in terms of `self` rather than > `from`, and to further reduce ambiguity by forcing manual stride > computation and using an explicit "offset" label. The call site will > be just as explicit

Re: [swift-evolution] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

On Tue, Sep 5, 2017 at 17:16 Taylor Swift wrote: > I’m fine with most of this > > On Tue, Sep 5, 2017 at 4:49 PM, Andrew Trick wrote: > >> >> On Sep 5, 2017, at 9:53 AM, Taylor Swift wrote: >> >> we agreed to deprecate the strided at:? Note that >> UnsafeMutableRawBufferPointer would still need

Re: [swift-evolution] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

On Tue, Sep 5, 2017 at 5:16 PM, Taylor Swift wrote: > I’m fine with most of this > > On Tue, Sep 5, 2017 at 4:49 PM, Andrew Trick wrote: > >> >> On Sep 5, 2017, at 9:53 AM, Taylor Swift wrote: >> >> we agreed to deprecate the strided at:? Note that >> UnsafeMutableRawBufferPointer would still n

Re: [swift-evolution] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

I’m fine with most of this On Tue, Sep 5, 2017 at 4:49 PM, Andrew Trick wrote: > > On Sep 5, 2017, at 9:53 AM, Taylor Swift wrote: > > we agreed to deprecate the strided at:? Note that > UnsafeMutableRawBufferPointer would still need a byteOffset: argument. > I’m also still not comfortable with

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

> On Sep 2, 2017, at 00:30, Fabian Ehrentraud > wrote: > > > Am 03.08.2017 um 02:09 schrieb Jordan Rose via swift-evolution > mailto:swift-evolution@swift.org>>: > >> David Hart recently asked on Twitter >> if there was a good >> w

Re: [swift-evolution] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

> On Sep 5, 2017, at 9:53 AM, Taylor Swift wrote: > > we agreed to deprecate the strided at:? Note that > UnsafeMutableRawBufferPointer would still need a byteOffset: argument. I’m > also still not comfortable with duplicating functionality for the sake of > having two names I’ll summarize w

[swift-evolution] [Proposal] Explicit Synthetic Behaviour

Some of you will have seen my impassioned pleas on the synthesised Equatable/Hashable thread against implementing implicit synthesised behaviour on protocols that must, by necessity, make assumptions about a concrete type that could be incorrect. For those that haven't, the concept of synthetic

Re: [swift-evolution] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

> On Sep 1, 2017, at 10:27 PM, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0184 "Unsafe[Mutable][Raw][Buffer]Pointer: add missing > methods, adjust existing labels for clarity, and remove deallocation size" > begins now and runs through Septemb

Re: [swift-evolution] [Pitch] DateComponents{Encoding/Decoding}Strategy in JSON{Encoder/Decoder}

Hi Itai, I think my first pitch email was not clear enough and want to sorry for that. I have been working on a calendar app for awhile and understand the concept of calendar or date and time programming in some level. I didn’t pitch the idea of encoding and decoding `Date` value with this `Da

Re: [swift-evolution] [Pitch] DateComponents{Encoding/Decoding}Strategy in JSON{Encoder/Decoder}

Hi Pitiphong, Thanks for pitching this! My main question here is about the use case. Since encoding/decoding strategies apply to all values in a payload (whether or not those belong to types that you own), they inherently come with some risk. What is the use case in mind for needing to encode

Re: [swift-evolution] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

we agreed to deprecate the strided at:? Note that UnsafeMutableRawBufferPointer would still need a byteOffset: argument. I’m also still not comfortable with duplicating functionality for the sake of having two names On Tue, Sep 5, 2017 at 11:31 AM, Andrew Trick wrote: > I think we’ve agreed to a

Re: [swift-evolution] [Concurrency] async/await + actors

Fair enough! Tranks! Em ter, 5 de set de 2017 às 13:48, Pierre Habouzit escreveu: > On Sep 5, 2017, at 9:29 AM, Wallacy via swift-evolution < > swift-evolution@swift.org> wrote: > > "Actors are serial and exclusive, so this concurrent queue thing is not > relevant." > > Always? That is something

Re: [swift-evolution] [Concurrency] async/await + actors

> On Sep 5, 2017, at 9:29 AM, Wallacy via swift-evolution > wrote: > > "Actors are serial and exclusive, so this concurrent queue thing is not > relevant." > > Always? That is something i can't understand. The proposal actually cites the > "Intra-actor concurrency" As a future extension yes,

Re: [swift-evolution] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

I think we’ve agreed to a few minor updates to this proposal. Since there hasn’t been any other feedback on the thread it may be worth posting an amended proposal so we all know what we’ve agreed on. -Andy > On Sep 3, 2017, at 8:23 PM, Andrew Trick via swift-evolution > wrote: > > >> On Sep

Re: [swift-evolution] [Concurrency] async/await + actors

"Actors are serial and exclusive, so this concurrent queue thing is not relevant." Always? That is something i can't understand. The proposal actually cites the "Intra-actor concurrency" "Also, int he QoS world, using reader writer locks or private concurrent queues this way is not terribly great

Re: [swift-evolution] [Concurrency] A slightly different perspective

Thanks Pierre, When I answered, I was using my smartphone, so I copied the first code snippet from stackoverflow I found and remove some words. And in that case I'm happy to be a flawed example, and yet, its was most voted on stackoverflow. (the full exemple also does other mistakes). As Jonathan

Re: [swift-evolution] [SE-0155][Discuss] The role of labels in enum case patterns

> On Sep 5, 2017, at 3:07 AM, gs. via swift-evolution > wrote: > > > This becomes false in exactly the situation that you described where there > are two projections with similar structure, no? Labels would remove ambiguity > here. > TJ That depends on what names are bound. If the bound

Re: [swift-evolution] [SE-0155][Discuss] The role of labels in enum case patterns

This becomes false in exactly the situation that you described where there are two projections with similar structure, no? Labels would remove ambiguity here. TJ > On Sep 4, 2017, at 19:35, Matthew Johnson wrote: > > If the bound name clearly communicates the purpose of the associated value