[swift-evolution] Objective-C’s @compatibility_alias => Swift’s typealias?
panajev at gmail.com
Fri Jul 1 01:49:25 CDT 2016
+1 for Swift 3.
Sent from my iPhone
> On 1 Jul 2016, at 04:08, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
>> On Jun 30, 2016, at 3:16 PM, Ayaka Nonaka via swift-evolution <swift-evolution at swift.org> wrote:
>> Hi Swift community,
>> I was wondering if bridging Objective-C’s @compatibility_alias to Swift’s typealias is something that we have considered adding support for.
>> For example, @compatibility_alias is useful for things like adding an alias like DCColor for UIColor and NSColor depending on the target. Here’s an example from our codebase:
>> // For color compatibility, we alias DCColor to the appropriate class
>> #if DC_TARGET_MOBILE
>> #import <UIKit/UIKit.h>
>> @compatibility_alias DCColor UIColor;
>> #import <Cocoa/Cocoa.h>
>> @compatibility_alias DCColor NSColor;
>> We expected DCColor to be exposed to our Swift code, but it turns out that it is not. I’d imagine that we’re not the only ones using @compatibility_alias for similar things and other things that are useful. It would be really cool to see seamless bridging between @compatibility_alias and typealias, especially since we’ve seen a lot of other great backwards compatibility features in Swift 3.0 like importing lightweight-generics and #keyPath.
> It definitely makes sense for @compatibility_alias to map to ‘typealias’, and I’d consider it a bug fix that doesn’t need a proposal. Thanks for bringing this up! I had no idea anyone knew about or used @compatibility_alias...
> - Doug
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution