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

2017-07-06 Thread Robert Bennett via swift-evolution
I agree with Brent (and others) that this is sugar worth having. If keypaths had been introduced earlier in the language’s evolution, array.map { $0.property } would look as ugly, and as Brent put it, as noisy, as array.map { f($0) }; we only accept it because we’ve had no better alternative.

[swift-evolution] [Proposal] Introduces endianness specific type

2017-07-06 Thread Susan Cheng via swift-evolution
IMO, it has unclear representation when FixedWidthInteger working with endianness specific type. so I want to introduce the endianness specific wrapper: public struct BEInteger : FixedWidthInteger { public var bigEndian: BEInteger { get } public var littleEndian: LEInteger { get

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

2017-07-06 Thread Xiaodi Wu via swift-evolution
The lesson I took away from SE-0110 is that conveniences, once offered, are disruptive to take away. People who don't delve deeply into the reasons that make the conveniences unworkable in the grand scheme of things are upset when these features are taken away because specific use cases are made

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

2017-07-06 Thread Brent Royal-Gordon via swift-evolution
> On Jul 6, 2017, at 9:13 AM, Dave Abrahams wrote: > > I'm not sure what you're objecting to about this. Is it the very > appearance of curly braces? I went to bed thinking that maybe I should have explained that better, and I guess I was right. ;^) Here's why I think we

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

2017-07-06 Thread Benjamin Herzog via swift-evolution
Thanks for the feedback! I also like the idea where this is pivoting and would like to think deeper about the topic and possible solutions. I will change the proposal and polish it. I would still like to use this thread to get more input if there is more. __ Benjamin Herzog

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

2017-07-06 Thread Dave Abrahams via swift-evolution
on Wed Jul 05 2017, Brent Royal-Gordon wrote: >> On Jul 5, 2017, at 2:23 PM, Dave Abrahams via swift-evolution >> wrote: >> >> I am not convinced this syntactic sugar is worth complicating the >> language or library for, > > For what it's worth, I think it is

Re: [swift-evolution] explicitly mark synthesized init as public

2017-07-06 Thread Matthew Johnson via swift-evolution
> On Jul 6, 2017, at 10:17 AM, Benjamin Spratling via swift-evolution > wrote: > > Often I want to separate my data model into a separate framework from my UI. > This enables separation of data and logic tests from UI tests. And sharing a > common data model

[swift-evolution] explicitly mark synthesized init as public

2017-07-06 Thread Benjamin Spratling via swift-evolution
Often I want to separate my data model into a separate framework from my UI. This enables separation of data and logic tests from UI tests. And sharing a common data model between multiple apps, such as a end-user facing app and a back-of-house app. I also like to use structs to support

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

2017-07-06 Thread Brent Royal-Gordon via swift-evolution
> On Jul 5, 2017, at 2:23 PM, Dave Abrahams via swift-evolution > wrote: > > I am not convinced this syntactic sugar is worth complicating the > language or library for, For what it's worth, I think it is *totally* worth complicating the language or library. The