[swift-evolution] Pitch: Import Objective-C Constants as Enums

Douglas Gregor dgregor at apple.com
Fri Jan 29 12:53:56 CST 2016


> On Jan 29, 2016, at 10:48 AM, Douglas Gregor <dgregor at apple.com> wrote:
> 
> 
>> On Jan 29, 2016, at 9:19 AM, Jeff Kelley via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Hi everyone!
>> 
>> 	I know there has been a lot of activity on other, larger proposals, but does anyone have any more feedback here? Proposal link: https://github.com/SlaunchaMan/swift-evolution/blob/import-objc-constants/proposals/0000-import-objc-constants.md <https://github.com/SlaunchaMan/swift-evolution/blob/import-objc-constants/proposals/0000-import-objc-constants.md>
> I have a few more comments.
> 
> typedef NSString * HKQuantityTypeIdentifier __attribute__((struct(string)));
> 
> I don’t think “struct(string)” is the right (Objective-)C attribute here. For one, we don’t need to restate the type “string” at all: we know what the type is because it’s the type behind the typedef. Additionally, this is a Swift-specific mapping. How about __attribute__((swift_struct_wrapper)), to indicate that it’s Swift-specific and that the annotated type is a wrapper struct?

Hrm, maybe

 	__attribute__((swift_wrapper(struct)))

to leave space for

	__attribute__((swift_wrapper(enum))

which I’m sure we will want as well. I’m somewhat inclined to want both in the same proposal so we don’t have to revisit this later, because there are use cases for both.

> 
> I think you need to clarify a few things:
> 
> (1) How are the names of the constants transformed? It looks like you’re chopping off the common prefix between the type name and the enum constant name. Should the result have initial lowercase letters?
> (2) What happens if additional constants are defined in a different module? (I assume that the new “static let”s go into an extension)
> 
> Otherwise, LGTM!
> 
> 	- Doug
> 
>> 
>> Jeff Kelley
>> 
>> SlaunchaMan at gmail.com <mailto:SlaunchaMan at gmail.com> | @SlaunchaMan <https://twitter.com/SlaunchaMan> | jeffkelley.org <http://jeffkelley.org/>
>>> On Jan 22, 2016, at 4:14 PM, Jeff Kelley <SlaunchaMan at gmail.com <mailto:SlaunchaMan at gmail.com>> wrote:
>>> 
>>> I have updated the proposal <https://github.com/SlaunchaMan/swift-evolution/blob/import-objc-constants/proposals/0000-import-objc-constants.md> to use struct over enum (https://github.com/SlaunchaMan/swift-evolution/blob/import-objc-constants/proposals/0000-import-objc-constants.md <https://github.com/SlaunchaMan/swift-evolution/blob/import-objc-constants/proposals/0000-import-objc-constants.md>).
>>> 
>>>> On Jan 20, 2016, at 11:01 PM, Douglas Gregor <dgregor at apple.com <mailto:dgregor at apple.com>> wrote:
>>>> 
>>>> FWIW, I suggest that you put “String” somewhere in the title of your proposal when you revise it.
>>> 
>>> Would this need to be limited to strings? There are other “magic constants” that could conceivably be imported as structs—I’m thinking, for instance, error codes.
>>> 
>>> 
>>> Jeff Kelley
>>> 
>>> SlaunchaMan at gmail.com <mailto:SlaunchaMan at gmail.com> | @SlaunchaMan <https://twitter.com/SlaunchaMan> | jeffkelley.org <http://jeffkelley.org/>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160129/bca9738c/attachment.html>


More information about the swift-evolution mailing list