[swift-evolution] [Proposal] Enum string interoperability with Objective-C and Swift

[Jean-Daniel]

In your example, you don't prepend the prefix but the whole name (JRKCity), so we don’t need to define what the prefix is.

> Le 5 janv. 2017 à 20:13, Jeff Kelley via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> Would that prepend the prefix on individual members? If so that’s perfect!
> 
> 
> Jeff Kelley
> 
> SlaunchaMan at gmail.com <mailto:SlaunchaMan at gmail.com> | @SlaunchaMan <https://twitter.com/SlaunchaMan> | jeffkelley.org <http://jeffkelley.org/>
> On Thu, Jan 5, 2017 at 2:01 PM, Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>> wrote:
> Is there a reason you're unsatisfied with `@objc(JRKCity)`?
> 
> 
> 
> On Thu, Jan 5, 2017 at 12:48 Jeff Kelley via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> Since it’s still common to see prefixes in use in Objective-C, I wonder if we could add that with a new attribute:
> 
> @objcprefix(JRK) enum City: String {
> 	case NewYork = "New York"
> }
> 
> Would then appear in Objective-C as:
> 
> typedef NSString * JRKCity;
> static JRKCity const JRKCityNewYork = @"New York";
> 
> It’s a minor tweak, but would help especially with mixed-language source code where the Objective-C code is still prefixed.
> 
> 
> Jeff Kelley
> 
> SlaunchaMan at gmail.com <mailto:SlaunchaMan at gmail.com> | @SlaunchaMan <https://twitter.com/SlaunchaMan> | jeffkelley.org <http://jeffkelley.org/>
> 
> On Wed, Jan 4, 2017 at 5:51 PM, Derrick Ho via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> The underline can be omitted. To remain more consistent. 
> 
> enum City: String {
> case NewYork = "New York"
> } 
> 
> typedef NSString * City;
> static City const CityNewYork = @"New York";
> 
> 
> 
> 
> On Wed, Jan 4, 2017 at 2:22 PM Rod Brown <rodney.brown6 at icloud.com <mailto:rodney.brown6 at icloud.com>> wrote:
> I'm not part of the core team, of course, but I like this change in principle.
> 
> My one concern in this case would be choosing a naming convention for the back port that makes sense both ways. The naming convention you propose ( EnumName_EnumCase) seems inconsistent with the current import of strings from Obj-C to Swift. Could we find a way to unify them?
> 
> On 31 Dec 2016, at 4:15 am, Derrick Ho via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> I'm trying to revive an old thread. I'd like to hear from the community.
>> 
>> Can we make a swift enum string interoperable with Objective-C?
>> 
>> Currently NS_STRING_ENUM ports from objective-c to swift but not the other way around.
>> 
>> I feel that if you can go one direction you should be able to go back.
>> 
>> @objc
>> enum City: String {
>> case NewYork = "New York"
>> } 
>> 
>> Make this available as a global string in objective -c ?
>> On Wed, Nov 23, 2016 at 5:55 AM Derrick Ho <wh1pch81n at gmail.com <mailto:wh1pch81n at gmail.com>> wrote:
>> I think enum strings should gain better interoperability with swift. Something like this:
>> 
>>     enum City: String {
>>        case NewYork = "New York"
>>     } 
>> 
>> This can be ported over to Objective-c like this:
>> 
>>     typedef NSString * City;
>>     static City const City_NewYork = @"New York";
> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> 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/20170105/e4f47ef6/attachment.html>