Re: [swift-evolution] [Pitch] New Version of Array Proposal

2017-07-22 Thread Taylor Swift via swift-evolution
Hi, I’ve been watching this proposal for a while but didn’t get to read it in detail until now. I really like this idea and it’s very comprehensive and well-thought out. Some feedback: 1. I got very confused reading through the document the first time through. You’re introducing a huge amount of

[swift-evolution] [Pre-pitch] "common" fields for union-style enumerations?

2017-07-22 Thread Daryle Walker via swift-evolution
Way back in the macOS pre-X days, I remember some APIs had types like: struct Sample1 { int a; int b; float c; }; struct Sample2 { int a; int b; double d; }; The types are supposed to be related, and it was supposed to be guaranteed that if you type-punned Sample1 to or from Sample2, the

Re: [swift-evolution] [RFC] Definitive Initialization and Incompatibilities with Fixed-size Arrays

2017-07-22 Thread Daryle Walker via swift-evolution
> On Jul 22, 2017, at 3:02 PM, Chris Lattner wrote: > > On Jul 18, 2017, at 1:00 PM, Daryle Walker via swift-evolution > wrote: >>> On Jul 17, 2017, at 3:26 AM, Félix Cloutier wrote: >>> >>> I think that you're getting ahead

[swift-evolution] [Pitch] New Version of Array Proposal

2017-07-22 Thread Daryle Walker via swift-evolution
It’s at >. * Try to clarify that fixed-size arrays are a new kind of compound type, not a (ridiculously magical) library generic type. * Change the separator

Re: [swift-evolution] [RFC] Definitive Initialization and Incompatibilities with Fixed-size Arrays

2017-07-22 Thread Chris Lattner via swift-evolution
On Jul 18, 2017, at 1:00 PM, Daryle Walker via swift-evolution wrote: >> On Jul 17, 2017, at 3:26 AM, Félix Cloutier wrote: >> >> I think that you're getting ahead of yourself. Fixed-size arrays are still >> useful even if they have to have been

Re: [swift-evolution] Proposal revision mechanics + schedule

2017-07-22 Thread Chris Lattner via swift-evolution
On Jul 21, 2017, at 8:12 AM, Nevin Brackett-Rozinsky via swift-evolution wrote: > That said, I think it is highly important that we have clarity regarding what > *is* the proper time, method, and process for raising issues with and > suggesting modifications to

Re: [swift-evolution] [swift-evolution-announce] Revision review: SE-104: Protocol-oriented integers

2017-07-22 Thread Dave Abrahams via swift-evolution
on Fri Jul 21 2017, Xiaodi Wu wrote: > Over the last months, I started two threads to discuss revisions to > SE-0104; these received essentially no reply. Yes, I'm sorry I didn't have time to reply at the time. These proposed revisions are, effectively, part of my

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

2017-07-22 Thread Benjamin Herzog via swift-evolution
I also thought about adding a computed property or method to KeyPath to get the callable behaviour, but it is really hard to distinguish between the keypath and it's method, especially in the literal syntax. Adding a separator like # would help but would bring the same new complexity like a prefix

Re: [swift-evolution] [Pitch] Scoped @available

2017-07-22 Thread Rod Brown via swift-evolution
This is something I’m dealing with as a framework author as well. I’m stumped coming up with anything better than your latter idea of “outside” even though I’m not really a fan. Either way, I think that deprecating outside makes some sense from a framework developer’s perspective. You may need

Re: [swift-evolution] [swift-evolution-announce] Revision review: SE-104: Protocol-oriented integers

2017-07-22 Thread Xiaodi Wu via swift-evolution
Indeed, this thread has been derailed. I should ask myself to open a separate thread to talk about these concerns :) On Sat, Jul 22, 2017 at 06:16 Víctor Pimentel wrote: > > > Sent from my iPhone > > On 21 Jul 2017, at 23:57, Xiaodi Wu via swift-evolution < >

Re: [swift-evolution] [swift-evolution-announce] Revision review: SE-104: Protocol-oriented integers

2017-07-22 Thread Víctor Pimentel via swift-evolution
Sent from my iPhone > On 21 Jul 2017, at 23:57, Xiaodi Wu via swift-evolution > wrote: > > It is no fun to call people out on this, but I'll do it if no one else will. > If someone starts a conversation to talk about X in a public forum, anyone is > free to join

Re: [swift-evolution] Swift's 'observe()' doesn't work for key paths with optionals?

2017-07-22 Thread Brent Royal-Gordon via swift-evolution
> On Jul 22, 2017, at 12:12 AM, William Shipley via swift-evolution > wrote: > > submodelObservation = observe(\.controller.submodel) { object, change > in > // code > } > > > @objc dynamic internal var controller: Controller? > > in the

[swift-evolution] Swift's 'observe()' doesn't work for key paths with optionals?

2017-07-22 Thread William Shipley via swift-evolution
When I try to observe a key path that includes an optional (“controller” in this case) in Swift, I get a compiler error saying ‘Type of expression is ambiguous without more context’ on the backslash in this statement: submodelObservation = observe(\.controller.submodel) { object, change