[swift-evolution] [Review] SE-0191: Eliminate IndexDistance from Collection

+1. Feels more Swifty to keep things simple when additional complexity isn’t warrented. > Hello Swift community, > > > The review of SE-0191 "Eliminate IndexDistance from Collection" begins now > and runs through December 3, 2017. The proposal is available here: > > >

[swift-evolution] SE-165: Dictionary & Set Enhancements

+1. These are great, swifty additions to the standard library. Good job Nate Cook! > Hello, Swift community! > > The review of "SE-165: Dictionary Enhancements" begins now and runs > through next Tuesday, April 11th. The proposal is available here: >

[swift-evolution] Unify the way properties and methods work to make key-value coding more natural

I like the .get syntax better than \ I’d be okay with the slightly more verbose .getter Foo.a could return a tuple: (getter: (Foo) -> () -> A, setter: (Foo) -> (A) -> ()) > Recently I’ve seen some upcoming changes for #keyPath, but the whole things > look a bit messy to me. Today I came up with

[swift-evolution] [Review] SE-0167: Swift Encoders

-1. I left my feedback for this proposal and SE-0166 on the other thread, but TLDR; I think this is premature until we add true reflection capabilities to Swift. > Hello Swift community, > > > The review of SE-0167 "Swift Encoders" begins now and runs through April 12, > 2017. The proposal is

[swift-evolution] [Review] SE-0166: Swift Archival & Serialization

-1. I support the motivation, but I think this proposal and SE-0167 are too premature. Don’t get me wrong, I think that Swift leaves much to be desired as far as serialization/deserialization goes. However I think that these proposals are putting the cart before the horse. I think we first

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

Yes. I'd prefer to keep unapplied method references the same and do properties the same way IMHO. On Thu, Apr 6, 2017 at 12:05 PM, Douglas Gregor wrote: > > On Apr 6, 2017, at 11:01 AM, Brad Hilton wrote: > > -1. Not a huge fan of the back slash.

[swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

-1. Not a huge fan of the back slash. Doesn’t make sense considering we can refer to unapplied method references without the backslash. Maybe we can settle on some unified syntax for both? How about Person.name.get / Person.name.set for getter/setter references. > Hello Swift community, > >

[swift-evolution] [Review] SE-0159: Fix Private Access Levels

Big -1 from me. The introduction of private/fileprivate access levels was a huge win for Swift 3. I would really hate to see it go. > Hello Swift community, > > The review of SE-0159 "Fix Private Access Levels" begins now and runs through > March 27, 2017. The proposal is available here: > >

[swift-evolution] [Swift4] Mailing list vs. Forum

+1. I would love to see Swift Evolution on Slack or a forum, it would be so much easier to manage. Brad > Branching... > > On Fri, Jul 29, 2016 at 5:22 PM, Chris Lattner via > swift-evolutionwrote: > > On Jul 29, 2016, at 5:14 PM,

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

I completely agree with rparada and give a strong, strong, strong -1 to this proposal. To make classes non-subclassable by default is only going to lead to unanticipated pain and frustration. Also agree with other comments that subclassable and overridable conflate access control with class

[swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint

> What is your evaluation of the proposal? I think it’s good to have this functionality in the standard library, but it seems a bit inconsistent with other Swift math operators which are declared as global functions such as abs, max, +, -, /, *, %, etc. > Is the problem being addressed

[swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

> What is your evaluation of the proposal? -1. Argument labels can have meaning and are very useful, especially for default parameter names in closures: ```// Declaration func handleResponse(handler: (response: Response) -> ()) // Callsite handleResponse { response in // response automatically

[swift-evolution] [Review] SE-0107: UnsafeRawPointer API

* What is your evaluation of the proposal? -1. It seems like the author is trying to solve a non-problem. The pointer APIs already work very well with enough due warning that they are unsafe. This change will just make them even more cumbersome to work with. * Is the problem being addressed

[swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

+1. I agree that this could be a problem, especially if you’re importing a lot of similar modules. I like the `from` keyword, as I feel that is consistent with the language grammer. My vote would be for proposal #4. > Hello, everyone. > > I want to discuss the problem of name ambiguity when a

[swift-evolution] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

>* What is your evaluation of the proposal? +1. Having consistent conventions makes sense to me. I’d prefer `Initializable` to `Creatable` which sounds weird to me, but otherwise sounds great. >* Is the problem being addressed significant enough to warrant a change to >Swift? I think semantic

Re: [swift-evolution] [Pitch] Allow nested protocol declarations

for protocols. On Thu, Apr 28, 2016 at 5:27 PM, Douglas Gregor <dgre...@apple.com> wrote: > > On Apr 28, 2016, at 10:15 AM, Brad Hilton via swift-evolution < > swift-evolution@swift.org> wrote: > > Type nesting allows some convenient and straightforward semantics tha

[swift-evolution] [Pitch] Allow nested protocol declarations

Type nesting allows some convenient and straightforward semantics that we see inside the Swift standard library such as views on String like String.CharacterView, String.UnicodeScalarView, etc. However a protocol cannot be nested in a type and gives a non-obvious error that the “Declaration is

[swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)

The Completing Generics Manifesto suggests a more universal solution with generic value parameters which is my vote: Generic value parameters Currently, Swift’s generic parameters are always types. One could imagine allowing generic parameters that are values, e.g., struct MultiArray