[swift-evolution] Objective-C’s @compatibility_alias => Swift’s typealias?
Harlan Haskins
harlan at harlanhaskins.com
Thu Jun 30 18:36:56 CDT 2016
+1. Robert and I are toying with an implementation right now; it’s really straightforward.
— Harlan
> 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;
> #else
> #import <Cocoa/Cocoa.h>
> @compatibility_alias DCColor NSColor;
> #endif
>
> 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.
>
> Thanks for reading! :D
>
> Ayaka
>
> --
> Ayaka Nonaka
> @ayanonagon <https://twitter.com/ayanonagon> | www.ayaka.me <http://www.ayaka.me/>_______________________________________________
> 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/20160630/c0fd9d23/attachment.html>
More information about the swift-evolution
mailing list