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

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 >> > wrote: >> I think what you’re really asking for here is the “future” case mentioned in >>

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

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

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

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

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

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

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

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

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

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

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

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:

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

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

> 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

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

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

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

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

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

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

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

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

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:

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

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

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

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,

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

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

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

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

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

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 >> > wrote: >> >> I've taken everyone's feedback into

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

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