+1 I was just thinking the same thing a few days ago, thanks for bringing it up!
On Friday, 1 July 2016, Sean Heber via swift-evolution < [email protected]> wrote: > Makes sense to me! > > l8r > Sean > > Sent from my iPad > > On Jun 30, 2016, at 5:16 PM, Ayaka Nonaka via swift-evolution < > [email protected] > <javascript:_e(%7B%7D,'cvml','[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] > <javascript:_e(%7B%7D,'cvml','[email protected]');> > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
