Re: [swift-evolution] Enums and Source Compatibility

> On 7 Sep 2017, at 2:33 pm, Chris Lattner via swift-evolution > wrote: > > >> On Sep 5, 2017, at 5:19 PM, Jordan Rose via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I've taken everyone's feedback into consideration and written this up as a >> proposal: >> https://

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

okay so I think so far what’s been agreed on is *1*. rename “Bytes” to “Memory” in the raw pointer API. Note: this brings the `copyBytes(from:)` collection method into the scope of this proposal *2*. change raw offsets to be in terms of bytes, not typed strides. This argument will be called `atBy

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

> On 7 Sep 2017, at 07:05, Chris Lattner via swift-evolution > wrote: > > >> On Sep 5, 2017, at 7:31 PM, Eagle Offshore via swift-evolution >> wrote: >> >> OK, I've been watching this thing for a couple weeks. >> >> I've done a lot of GCD network code. Invariably my completion method sta

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

> On Sep 5, 2017, at 7:31 PM, Eagle Offshore via swift-evolution > wrote: > > 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 t

Re: [swift-evolution] Enums and Source Compatibility

> On Sep 5, 2017, at 5:19 PM, Jordan Rose via swift-evolution > wrote: > > 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] [Proposal] Explicit Synthetic Behaviour

>> On Sep 6, 2017, at 1:32 AM, Haravikk via swift-evolution >> wrote: >> >> As a general rule I would argue that Mirrors should almost never be used for >> any purpose, except perhaps debugging; in production code they can lead to >> subtle and misleading problems, not to mention any performanc

Re: [swift-evolution] Enums and Source Compatibility

Hi Brent, Thanks for the analysis of the issues here. I think you’re right that there are two major types of enums, and that there are a set developers tend to switch on that are usually fixed, where additional cases won’t make sense. I think there are several issues that I see with these diffe

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

> On Sep 6, 2017, at 5:17 PM, Taylor Swift wrote: > > > > On Sep 6, 2017, at 7:01 PM, Andrew Trick > wrote: > >> >>> On Sep 6, 2017, at 4:54 PM, Taylor Swift >> > wrote: >>> The semantics of buffer.deallocate() needs to be: free `b

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

> On Sep 6, 2017, at 7:01 PM, Andrew Trick wrote: > > >>> On Sep 6, 2017, at 4:54 PM, Taylor Swift wrote: >>> >>> The semantics of buffer.deallocate() needs to be: free `buffer.count` bytes >>> of memory at `buffer.baseAddress`. So, that will always be the fast path! >>> Kelvin, do you agre

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

> On Sep 6, 2017, at 6:56 PM, Andrew Trick wrote: > > >>> On Sep 6, 2017, at 4:46 PM, Taylor Swift wrote: >>> >>> A sized implementation may fail more obviously when you violate the >>> contract in the future. Not having sized deallocation is a known deficiency >>> of the C model we've bee

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

> On Sep 6, 2017, at 4:54 PM, Taylor Swift wrote: > >> The semantics of buffer.deallocate() needs to be: free `buffer.count` bytes >> of memory at `buffer.baseAddress`. So, that will always be the fast path! >> Kelvin, do you agree with that? > > this could be problematic if you have multiple

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

> On Sep 6, 2017, at 4:46 PM, Taylor Swift wrote: > >> A sized implementation may fail more obviously when you violate the contract >> in the future. Not having sized deallocation is a known deficiency of the C >> model we've been fairly diligent about avoiding in Swift's allocation >> interf

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

> On Sep 6, 2017, at 6:27 PM, Andrew Trick wrote: > > >> On Sep 6, 2017, at 3:42 PM, Joe Groff wrote: >> >> >>> On Sep 6, 2017, at 3:26 PM, Andrew Trick wrote: >>> >>> > On Sep 6, 2017, at 2:31 PM, Joe Groff wrote: > > > The fact that we’re using malloc and free is alr

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

> On Sep 6, 2017, at 5:12 PM, Joe Groff wrote: > > >> On Sep 6, 2017, at 3:07 PM, Taylor Swift wrote: >> >> >> >>> On Sep 6, 2017, at 4:31 PM, Joe Groff wrote: >>> >>> On Sep 6, 2017, at 2:28 PM, Andrew Trick wrote: >> On Sep 6, 2017, at 1:12 PM, Joe Groff via swif

Re: [swift-evolution] Contextualizing async coroutines

> On Sep 2, 2017, at 1:57 AM, Brent Royal-Gordon wrote: > >> On Aug 31, 2017, at 11:35 AM, Joe Groff via swift-evolution >> wrote: >> >> # Coroutine context >> >> # `onResume` hooks > > `onResume` hooks seem like a really good way to, essentially, allow arbitrary > concurrency primitives t

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

> On Sep 6, 2017, at 3:42 PM, Joe Groff wrote: > > >> On Sep 6, 2017, at 3:26 PM, Andrew Trick wrote: >> >> >>> On Sep 6, 2017, at 2:31 PM, Joe Groff wrote: >>> The fact that we’re using malloc and free is already part of the ABI because old libraries need to be able to de

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

> On Sep 5, 2017, at 1:02 PM, Haravikk via swift-evolution > wrote: > > This proposal idea is essentially for a new attribute @synthetic (name is up > for debate). This attribute is required for any default implementation that > includes reflective type compiler magic, use of the reflection AP

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

On Wed, Sep 6, 2017 at 5:42 PM, Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > the issue I'm trying to raise is that when those, and similar features, > are used in synthesised behaviour (default implementations based upon the > concrete type), that these behaviours should be o

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

> On Sep 6, 2017, at 3:26 PM, Andrew Trick wrote: > > >> On Sep 6, 2017, at 2:31 PM, Joe Groff wrote: >> >>> >>> The fact that we’re using malloc and free is already part of the ABI >>> because old libraries need to be able to deallocate memory allocated by >>> newer libraries. >> >> The

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

> On Sep 6, 2017, at 2:31 PM, Joe Groff wrote: > >> >> The fact that we’re using malloc and free is already part of the ABI because >> old libraries need to be able to deallocate memory allocated by newer >> libraries. > > The compiler doesn't ever generate calls directly to malloc and free,

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

> On Sep 6, 2017, at 3:07 PM, Taylor Swift wrote: > > > >> On Sep 6, 2017, at 4:31 PM, Joe Groff wrote: >> >> >>> On Sep 6, 2017, at 2:28 PM, Andrew Trick wrote: >>> >>> > On Sep 6, 2017, at 1:12 PM, Joe Groff via swift-evolution > wrote: > > > On Sep 6, 2017, at

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

> On Sep 6, 2017, at 4:31 PM, Joe Groff wrote: > > >> On Sep 6, 2017, at 2:28 PM, Andrew Trick wrote: >> >> On Sep 6, 2017, at 1:12 PM, Joe Groff via swift-evolution wrote: On Sep 6, 2017, at 1:06 PM, Taylor Swift wrote: > On Wed, Sep 6, 2

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

> On Sep 6, 2017, at 2:28 PM, Andrew Trick wrote: > > >> On Sep 6, 2017, at 1:12 PM, Joe Groff via swift-evolution >> wrote: >> >>> >>> On Sep 6, 2017, at 1:06 PM, Taylor Swift wrote: >>> >>> >>> >>> On Wed, Sep 6, 2017 at 12:41 PM, Joe Groff via swift-evolution >>> wrote: Curren

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

> On Sep 6, 2017, at 1:12 PM, Joe Groff via swift-evolution > wrote: > >> >> On Sep 6, 2017, at 1:06 PM, Taylor Swift wrote: >> >> >> >> On Wed, Sep 6, 2017 at 12:41 PM, Joe Groff via swift-evolution >> wrote: >>> Currently, memory is deallocated by an instance method on >>> UnsafeMutab

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

> On 6 Sep 2017, at 16:26, Eagle Offshore wrote: >> On Sep 6, 2017, at 1:32 AM, Haravikk via swift-evolution >> wrote: >> As a general rule I would argue that Mirrors should almost never be used for >> any purpose, except perhaps debugging; in production code they can lead to >> subtle and mi

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

> On Sep 6, 2017, at 1:06 PM, Taylor Swift wrote: > > > > On Wed, Sep 6, 2017 at 12:41 PM, Joe Groff via swift-evolution > wrote: > > Currently, memory is deallocated by an instance method on > > UnsafeMutablePointer, deallocate(count:). Like much of the Swift pointer > > API, performing t

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

On Wed, Sep 6, 2017 at 12:41 PM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > > Currently, memory is deallocated by an instance method on > UnsafeMutablePointer, deallocate(count:). Like much of the Swift pointer > API, performing this operation on a buffer pointer requires

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

Hi Itai, Thanks for a good and solid explanation. First I want to express my use case that was the reason I try to pitch this idea. We have a schedule service and the data model that represent the occurrence holds an information on what date of this occurrence was created in terms of a date str

Re: [swift-evolution] Enums and Source Compatibility

Here is an alternative view. I've been thinking about this and I feel that instead of adding this to an enum why not make RawRepresentable structs a swift construct. You could declare it like this: enum struct { case a, b, c } This would be a struct that acts like an enum but it is open li

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

Hi Pitiphong, Don’t worry — your original email was clear, and we are on the same page about `Date{En,De}codingStrategy` and `DateComponents{En,De}codingStrategy` being separate things. To clarify my points, though, there are two main things I want to say: 1. I think there is a mismatch here

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

> Currently, memory is deallocated by an instance method on > UnsafeMutablePointer, deallocate(count:). Like much of the Swift pointer API, > performing this operation on a buffer pointer requires extracting > baseAddress! and count. It is very common for the allocation code above to be > immed

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

> On Sep 6, 2017, at 1:32 AM, Haravikk via swift-evolution > wrote: > > As a general rule I would argue that Mirrors should almost never be used for > any purpose, except perhaps debugging; in production code they can lead to > subtle and misleading problems, not to mention any performance i

Re: [swift-evolution] Enums and Source Compatibility

> On Sep 5, 2017, at 5:19 PM, Jordan Rose via swift-evolution > wrote: > > 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] Enums and Source Compatibility

Hi Jordan, The proposal looks very reasonable to me. I don’t have too strong an opinion on this topic, but it occurred to me that your discussion of `future` left out one possible design approach. We could restrict code in the `future` clause to be `break` or `fatalError()`. One of these is

Re: [swift-evolution] [Concurrency] Reactive streams as building blocks for actors etc.

I have put on Github three concurrency libraries ( https://github.com/hlovatt/Concurrency-Utilities): 1. Atomic - with `get`, `set`, and `update` methods 2. Future - with `get`, `cancel`, and `status` methods 3. Reactive Streams - with protocols `Processor`, `Producer`, `Subscriber`, and `Su

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

> On 6 Sep 2017, at 01:36, Robert Bennett wrote: > > 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 conform

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

> On 6 Sep 2017, at 01:36, Robert Bennett > wrote: > > 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 f

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

> On 5 Sep 2017, at 21:02, Haravikk wrote: > > Anyway, this is basically just a rough dump of the ideas for how the > synthesised Codable, Equatable and Hashable behaviours (and anything else > anyone can think of) should be changed before Swift 4 is released. Swift 4, Xcode 9 and iOS 11 will

Re: [swift-evolution] Enums and Source Compatibility

>> I see the logic of this position, but it traps at cases which are unforeseen >> unrelated to OS releases. As this proposal notes, there are cases that Apple >> uses internal of their frameworks that they consider private may still be >> passed through your API. >> >> For example, if there w

Re: [swift-evolution] Enums and Source Compatibility

> On Sep 6, 2017, at 8:50 AM, Rod Brown wrote: > > >> 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 her