Re: [swift-corelibs-dev] Unavailability macros for APIs that aren't going to be implemented on Linux?

On 28 Jul 2017, at 19:44, Tony Parker wrote: > > This sounds like a good plan to me. We’ll have to discuss the specifics of > what is marked unavailable this way, probably best via code review. > > I think we had more hope for some of the more-dynamic methods (e.g. >

Re: [swift-corelibs-dev] Unavailability macros for APIs that aren't going to be implemented on Linux?

This sounds like a good plan to me. We’ll have to discuss the specifics of what is marked unavailable this way, probably best via code review. I think we had more hope for some of the more-dynamic methods (e.g. NSSortDescriptor, NSExpression), but it does seem clear at this point that the

Re: [swift-corelibs-dev] Unavailability macros for APIs that aren't going to be implemented on Linux?

Hi Al, thanks for bringing this up. My view is that we shouldn't have API in the project which is never going to be implemented. The contents of swift-corelibs-foundation should represent a baseline of fundamental types and functionality which is useful to all applications and can be implemented

[swift-corelibs-dev] Unavailability macros for APIs that aren't going to be implemented on Linux?

I've pushed a change which will add an unavailability warning for a method which was deprecated at the point of being added to Swift, has never worked, and likely never will: https://github.com/apple/swift-corelibs-foundation/pull/1140