+1 for Swift 3. Sent from my iPhone
> On 1 Jul 2016, at 04:08, Douglas Gregor via swift-evolution > <[email protected]> wrote: > > >> 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. > > 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
