[swift-evolution] Review: Import Objective-C Constants as Swift Types

Brent Royal-Gordon brent at architechies.com
Thu Feb 18 20:07:08 CST 2016


>   Proposal link:
>     https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md
> 
> 	• What is your evaluation of the proposal?

I think it's an excellent idea. It not only improves the Swift bridging immensely, it actually improves the Objective-C APIs by making them more descriptive in a fairly natural way. It's easy for me to imagine a future version of clang warning about implicit conversions between `swift_wrapper` typedefs, which would improve even pure Objective-C code.

Actually, if I have one objection to this proposal, it's that the clang guys should probably take a look at it and see if they want to do something to `typedef` that helps both languages. I'd be willing to lose the `enum` feature, for instance, if this were instead an `__attribute__((newtype))` which affected both Swift and C family languages.

I also like that this is *not* some magic that happens in the API notes, but something that goes directly into the headers which you can use yourself.

> 	• Is the problem being addressed significant enough to warrant a change to Swift?

Yes. The type weaknesses of stringly typed Objective-C APIs affect Swift API names; to use an example mentioned in the proposal, the guidelines suggest the "Identifier" should be dropped when `-quantityTypeForIdentifier:` is bridged to Swift, but this isn't possible when the parameter is an untyped `String`.

Having said that, this isn't *as* high a priority as some of the other things planned for Swift 3. If we find we need to defer something, this proposal is a good candidate.

> 	• Does this proposal fit well with the feel and direction of Swift?

Absolutely. Anything that strengthens the typing of bridged APIs improves their Swiftiness, and a lot of Swift code interoperates with Objective-C.

> 	• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I've never used automatic bridging which added type information like this, but I have been known to use type trickery to add type information which is not technically required in both Objective-C and Swift. (For instance, I previously wrote something like `NSLayoutAnchor` which used unnecessary protocols to keep you from accidentally mixing X and Y axis constraints.) Creating synthetic types purely to avoid mistakes is often very helpful.

> 	• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick reading. I did follow the original thread, though not all that closely.

-- 
Brent Royal-Gordon
Architechies



More information about the swift-evolution mailing list