Objective-C’s @compatibility_alias => Swift’s typealias?


(Ayaka Nonaka) #1

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! :smiley:

Ayaka

···

--
Ayaka Nonaka
@ayanonagon <https://twitter.com/ayanonagon> | www.ayaka.me


(Harlan Haskins) #2

+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@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! :smiley:

Ayaka

--
Ayaka Nonaka
@ayanonagon <https://twitter.com/ayanonagon> | www.ayaka.me <http://www.ayaka.me/>_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Sean Heber) #3

Makes sense to me!

l8r
Sean

···

Sent from my iPad

On Jun 30, 2016, at 5:16 PM, Ayaka Nonaka via swift-evolution <swift-evolution@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! :smiley:

Ayaka

--
Ayaka Nonaka
@ayanonagon | www.ayaka.me
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Douglas Gregor) #4

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

···

On Jun 30, 2016, at 3:16 PM, Ayaka Nonaka via swift-evolution <swift-evolution@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.


(Ayaka Nonaka) #5

That’s so great to hear. Thank you! :slight_smile:

···

On Thu, Jun 30, 2016 at 4:36 PM, Harlan Haskins <harlan@harlanhaskins.com> 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 < > swift-evolution@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! :smiley:

Ayaka

--
Ayaka Nonaka
@ayanonagon <https://twitter.com/ayanonagon> | www.ayaka.me
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Ayaka Nonaka
@ayanonagon <https://twitter.com/ayanonagon> | www.ayaka.me


(Goffredo Marocchi) #6

+1 for Swift 3.

···

Sent from my iPhone

On 1 Jul 2016, at 04:08, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 30, 2016, at 3:16 PM, Ayaka Nonaka via swift-evolution <swift-evolution@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.

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Andrew Bennett) #7

+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 < swift-evolution@swift.org> wrote:

Makes sense to me!

l8r
Sean

Sent from my iPad

On Jun 30, 2016, at 5:16 PM, Ayaka Nonaka via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@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! :smiley:

Ayaka

--
Ayaka Nonaka
@ayanonagon <https://twitter.com/ayanonagon> | www.ayaka.me

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Nicholas Maccharoli) #8

+1

···

On Fri, Jul 1, 2016 at 8:47 AM, Ayaka Nonaka via swift-evolution < swift-evolution@swift.org> wrote:

That’s so great to hear. Thank you! :slight_smile:

On Thu, Jun 30, 2016 at 4:36 PM, Harlan Haskins <harlan@harlanhaskins.com> > 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 < >> swift-evolution@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! :smiley:

Ayaka

--
Ayaka Nonaka
@ayanonagon <https://twitter.com/ayanonagon> | www.ayaka.me
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Ayaka Nonaka
@ayanonagon <https://twitter.com/ayanonagon> | www.ayaka.me

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution