That’s so great to hear. Thank you! :) On Thu, Jun 30, 2016 at 4:36 PM, Harlan Haskins <[email protected]> wrote:
> +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 < > [email protected]> 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 > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > -- Ayaka Nonaka @ayanonagon <https://twitter.com/ayanonagon> | www.ayaka.me
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
