Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

* What is your evaluation of the proposal? In theory, it seems like a great idea, but I fear that it will be one of those small changes that have disastrous effects on migrating code to Swift 4. There will likely be a ton of confusing errors and warnings that amount to "just add @objc to everything

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

- What is your evaluation of the proposal? Definitely in favor of this. About halfway through the Swift 3 migration I gave up trying to think through where to use fileprivate and where to use private and just did a project level find and replace to use fileprivate everywhere. So far over the la

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

> Hello, Swift community! > > The review of "SE-165: Dictionary&Set Enhancements" begins now and runs > through next Tuesday, April 11th. The proposal is available here: > https://github.com/apple/swift-evolution/blob/master/proposals/0165-dict.md

[swift-evolution] [Review] SE-0168: Multi-Line String Literals

> Hello Swift community, > > The review of SE-0168 "Multi-Line String Literals" begins now and runs > through April 12, 2017. The proposal is available here: > > https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md > > Reviews are an important part o

[swift-evolution] [Pitch] Remove type-inference for stored property

This seems like something a linter should handle. > Hi all, > > In a discussion about inferring parameter types from default value, Slava > brought up some performance problems caused by type inference for stored > properties in side types: > > https://lists.swift.org/pipermail/swift-evolution

[swift-evolution] SE-163: String Revision: Collection Conformance, C Interop, Transcoding

> Hello, Swift community! > > The review of "SE-163: String Revision: Collection Conformance, C Interop, > Transcoding" begins now and runs through next Tuesday, April 11th. The > proposal is available here: > https://github.com/apple/swift-evolution/blob/master/proposals/0163-string-revision-1.

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

> Hello Swift community, > > The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for > Swift" begins now and runs through April 9, 2017. The revised proposal is > available here: > > https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md

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

https://gist.github.com/davbeck/e3b156d89b2e9d97bb5a61c59f8a07f7 # Async Await I love this proposal so much. Much of it is exactly how I’ve thought Swift’s concurrency model should look over the last year. Making async a return attribute just like `throws` seems like the right solution to me. Bu

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

An argument could be made that throws should precede the function definition, but since that ship has sailed, async should probably join it at the end, since it modifies the way the function returns. In other words, async doesn't change how the method gets run, but how and when it returns. On Thu,

[swift-evolution] Mark protocol methods with their protocol

With the transition from Swift 2 -> 3 I’ve started running into one particular issue VERY often (although it’s not necessarily specific to the transition). If a protocol method is optional (either because it is an @objc optional or because it has a default implementation) there is a risk that th

Re: [swift-evolution] Mark protocol methods with their protocol

Yeah, I figured it had probably come up before since I don’t follow evolution that closely, but it is, in my opinion and experience, Swift’s last pitfall. So many other pitfalls from ObjC and other languages have been solved with Swift, including this exact one (when it comes to subclassing). If

[swift-evolution] Proposal: Deprecate optionals in string interpolation

> The string interpolation is one of the strong sides of Swift, but also one of > its weaknesses. > > It has happened to me more than once that I've used the interpolation with an > optional by mistake and the result is then far from the expected result. > > This happened mostly before Swift 2.

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

> * What is your evaluation of the proposal? I’m on board with solving the problems outlined here. In particular, continuing to make Swift safe and fast by default and extending access and features as needed. And I am mostly on board with the solution proposed here. I have 2 big concerns: 1) U