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

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 >> > wrote: >> >> From the perspective of primarily an app

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

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 > >: > >> David Hart recently asked on Twitter >>

[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

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,

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:

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

[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

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

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

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

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 >> > wrote: >> >>> On Sep 4, 2017, at 10:36 AM, Chris

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

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] 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] [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 >> > wrote: >> >> On Sep 3, 2017, at 12:44 PM, Pierre

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

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

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

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

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 >

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

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

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

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

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