[swift-evolution] Review: Import Objective-C Constants as Swift Types
lists at duckcode.com
Fri Feb 19 02:48:36 CST 2016
> • 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.
More information about the swift-evolution