Review: Import Objective-C Constants as Swift Types

John_McCall · February 18, 2016, 11:41pm

Hello, Swift Community.

The review of the proposal "Import Objective-C Constants as Swift Types" begins now and runs through February 23rd, or this coming Tuesday.

The proposal is available here:

swift-evolution/0033-import-objc-constants.md at master · apple/swift-evolution · GitHub

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager (me). When replying, please try to consistently top-post, keeping the proposal link at the top of the message, like so:

Proposal link:
swift-evolution/0033-import-objc-constants.md at master · apple/swift-evolution · GitHub

This proposal is perfect. I can no longer imagine programming in Swift without this proposal in place.

> This proposal is completely in keeping with revolutionary principles.

Uniformity here makes my life easier, so thank you in advance.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have 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 here:

swift-evolution/process.md at master · apple/swift-evolution · GitHub

Thanks!

John McCall
Review Manager

···

Alice wrote on 3 Ventôse:

Brent_Royal-Gordon · February 19, 2016, 2:07am

  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

Curt_Clifton · February 19, 2016, 4:24am

Proposal link:
swift-evolution/0033-import-objc-constants.md at master · apple/swift-evolution · GitHub

• What is your evaluation of the proposal?

+1

This proposal is an improvement for both Objective-C and Swift/ObjC interop.

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

Yes. The existing stringly-typed constants are a significant pain point, both from a readability standpoint and as a source of errors.

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

Yes. Très Swifty.

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

I’ve used the typedef trick extensively in Objective-C, particularly when refactoring stringly-typed code to strong types.

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

I skimmed a bit of the original discussion. I read the proposal in detail.

Cheers,

Curt

···

-----------------------------------------------------------------------------
Curt Clifton, PhD
Software Engineer
The Omni Group
www.curtclifton.net

marco.masser · February 19, 2016, 8:48am

Proposal link:
https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md

• What is your evaluation of the proposal?

+1 because it’s just awesome.

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

I think so. I never liked these APIs that use strings for something that really should be a separate type, but I understand why they exist and I also wrote code like that myself. Having an API in Objective-C that takes string values is practical because NSStrings are often easier to deal with than primitives, e.g. putting them into containers like NSArray or NSDictionary. Swift doesn’t have those limitations, so it’s a good idea to use a separate, compiler-enforceable type.
Not to mention the benefit of having a self-documenting API.

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

I think so. Compiler-enforceable types, short but expressive names for constants and self-documenting APIs feel like Swift to me.
This also opens up the possibility to write an extension for the type in question, giving those enums or structs all kinds of convenience functionality. I tend to do this a lot in my Swift enums and structs.

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

No, I can’t think of a similar construct that I came across.

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

Just a quick reading the proposal and a good night’s sleep to think about it.

E_Maloney · February 19, 2016, 7:34pm

• What is your evaluation of the proposal?

+1

This is an elegant solution to representing Objective-C APIs meaningfully in Swift.

With this feature, Swift source code looks more beautiful.

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

Yes. Compiler-enforced type-safety is one of Swift's core benefits. Bugs that otherwise wouldn't be discovered until runtime are instead be caught up-front during the build. This will save lots of developers countless hours of debugging frustration!

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

Yes, for the reasons above.

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

A careful reading. No further study was required; I am already intimately familiar with this pain-point in Objective-C.

Shawn_Erickson · February 19, 2016, 8:10pm

• What is your evaluation of the proposal?

+1, it is a sensible approach to improve the interop of Objective-C code
and Swift. It also improves a general weakness/wart in
Cocoa/Foundation/etc. with the use of NSString (etc.) constants that are
not always obvious in their use domain. It not only improves Swift "import"
of ObjC API but also adds some clarity to the ObjC API itself when used
directly.

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

Swift?

I believe so, yes.

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

Yes it fits well.

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

N/A

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

A careful reading of the proposal and quick spot review of various
Cocoa/etc. headers to understand the problem domain more fully.

Rod_Brown · February 20, 2016, 7:18am

• What is your evaluation of the proposal?
+1. Love it. This is a sticking point when programming in Swift with Obj-C APIs and this technique to import them is clear and very sensible.

• Is the problem being addressed significant enough to warrant a change to Swift?
In the use of Obj-C APIs, yes. While this isn’t really core Swift, the area of the bridge that is related definitely would benefit from this.

• Does this proposal fit well with the feel and direction of Swift?
Absolutely. This will make Obj-C APIs feel a lot cleaner and simpler in Swift.

• 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 had much experience with bridging between languages, but from everything I’ve seen so far, this makes sense to implement.

• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Read the proposal, and have kept up to day with the discussion on Swift evolution,

Rod

···

On 19 Feb 2016, at 10:41 AM, John McCall via swift-evolution <swift-evolution@swift.org> wrote:

Hello, Swift Community.

The review of the proposal "Import Objective-C Constants as Swift Types" begins now and runs through February 23rd, or this coming Tuesday.

The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager (me). When replying, please try to consistently top-post, keeping the proposal link at the top of the message, like so:

  Proposal link:
    https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md

  This proposal is perfect. I can no longer imagine programming in Swift without this proposal in place.

  Alice wrote on 3 Ventôse:
  > This proposal is completely in keeping with revolutionary principles.

Uniformity here makes my life easier, so thank you in advance.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have 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 here:

  https://github.com/apple/swift-evolution/blob/master/process.md

Thanks!

John McCall
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

SlaunchaMan · March 7, 2016, 6:12pm

Hi John,

What’s the status of this review?

Jeff Kelley

SlaunchaMan@gmail.com | @SlaunchaMan <https://twitter.com/SlaunchaMan> | jeffkelley.org <http://jeffkelley.org/>

···

On Feb 18, 2016, at 6:41 PM, John McCall via swift-evolution <swift-evolution@swift.org> wrote:

Hello, Swift Community.

The review of the proposal "Import Objective-C Constants as Swift Types" begins now and runs through February 23rd, or this coming Tuesday.

The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager (me). When replying, please try to consistently top-post, keeping the proposal link at the top of the message, like so:

  Proposal link:
    https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md

  This proposal is perfect. I can no longer imagine programming in Swift without this proposal in place.

  Alice wrote on 3 Ventôse:
  > This proposal is completely in keeping with revolutionary principles.

Uniformity here makes my life easier, so thank you in advance.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have 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 here:

  https://github.com/apple/swift-evolution/blob/master/process.md

Thanks!

John McCall
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

John_McCall · March 7, 2016, 6:37pm

Hi John,

What’s the status of this review?

It’s been accepted. Sorry for not updating it in a timely manner; it’s now done.

John.

···

On Mar 7, 2016, at 10:12 AM, Jeff Kelley <slaunchaman@gmail.com> wrote:

Jeff Kelley

SlaunchaMan@gmail.com <mailto:SlaunchaMan@gmail.com> | @SlaunchaMan <https://twitter.com/SlaunchaMan> | jeffkelley.org <http://jeffkelley.org/>

On Feb 18, 2016, at 6:41 PM, John McCall via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello, Swift Community.

The review of the proposal "Import Objective-C Constants as Swift Types" begins now and runs through February 23rd, or this coming Tuesday.

The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager (me). When replying, please try to consistently top-post, keeping the proposal link at the top of the message, like so:

  Proposal link:
    https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md

  This proposal is perfect. I can no longer imagine programming in Swift without this proposal in place.

  Alice wrote on 3 Ventôse:
  > This proposal is completely in keeping with revolutionary principles.

Uniformity here makes my life easier, so thank you in advance.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have 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 here:

  https://github.com/apple/swift-evolution/blob/master/process.md

Thanks!

John McCall
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

marc_hoffman · March 15, 2016, 8:43pm

FWIW, GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. still does not seem to reflect that status?

···

On Mar 7, 2016, at 2:37 PM, John McCall <rjmccall@apple.com> wrote:

On Mar 7, 2016, at 10:12 AM, Jeff Kelley <slaunchaman@gmail.com <mailto:slaunchaman@gmail.com>> wrote:
Hi John,

  What’s the status of this review?

It’s been accepted. Sorry for not updating it in a timely manner; it’s now done.

John.

Jeff Kelley

SlaunchaMan@gmail.com <mailto:SlaunchaMan@gmail.com> | @SlaunchaMan <https://twitter.com/SlaunchaMan> | jeffkelley.org <http://jeffkelley.org/>

On Feb 18, 2016, at 6:41 PM, John McCall via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello, Swift Community.

The review of the proposal "Import Objective-C Constants as Swift Types" begins now and runs through February 23rd, or this coming Tuesday.

The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager (me). When replying, please try to consistently top-post, keeping the proposal link at the top of the message, like so:

  Proposal link:
    https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md

  This proposal is perfect. I can no longer imagine programming in Swift without this proposal in place.

  Alice wrote on 3 Ventôse:
  > This proposal is completely in keeping with revolutionary principles.

Uniformity here makes my life easier, so thank you in advance.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have 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 here:

  https://github.com/apple/swift-evolution/blob/master/process.md

Thanks!

John McCall
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org <mailto:swift-evolution-announce@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution-announce