[swift-evolution] [Review] SE-0160: Limiting @objc inference
brianaking at gmail.com
Wed Mar 22 20:25:44 CDT 2017
> * What is your evaluation of the proposal?
+1 in intent and -1 in detail.
I think reducing the amount of magic helps make swift more powerful and
easier to understand. This will force developers to add a few more `@objc`
tokens, but the consistency will help in the long run.
The last section in "Source Compatibility" calls out a few
problems, presents some possible solutions, but states that they are "Out
of scope for this proposal". Given the depth of migration issues that this
proposal is expected to incur, I think leaving out these details feels
short-sighted. If this proposal is approved, when are the 'out of scope'
A few specific opinions on the possibilities presented:
- I'd like a clearer explanation on how the inferred `dynamic` behavior
would change. I would prefer @objc to always infer dynamic or never infer
dynamic. Currently it's context dependent and confusing.
- I don't like forcing extension methods that are not `@objc` be flagged
`final`. That seems heavy handed.
- I'd like to get over-rides in extensions working!
That said, I'm new here, and I'm a net +0. I trust a good choice will be
> * Is the problem being addressed significant enough to warrant a change to
> * Does this proposal fit well with the feel and direction of Swift?
* If you have you used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
> More information about the Swift evolution process is available at:
> -Chris Lattner
> Review Manager
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution