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

Ian Partridge ian at poncho.org.uk
Fri Jul 28 09:27:04 CDT 2017

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 on a broad range of platforms
and operating systems.

I think it is more useful to developers who are porting their Swift
applications to other platforms if they are faced with a helpful message
when their app attempts to use unavailable API, rather than just "ERROR:
type 'NSWhatever' has no member 'foo'" - so I like your idea of using
@available annotations to guide people.

Once Swift 4 is out of the door, I think we should do a review of the
codebase and decide which of the remaining NSUnimplemented() are really

This will also help new contributors to swift-corelibs-foundation as they
will be able to be confident that every NSUnimplemented() is a genuine
opportunity to contribute.

Ian Partridge

On 28 July 2017 at 15:07, Alex Blewitt via swift-corelibs-dev <
swift-corelibs-dev at swift.org> wrote:

> 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
> There are some other types in Foundation which aren't likely to ever be
> implementable in Swift on Linux; Bundle.unload, NSPort/PortMessage,
> copy(with zone) etc. The majority of these methods use NSUnimplemented(),
> which means there are often unannounced runtime errors that you can get
> from something that compiled correctly.
> I'd like to suggest that we attempt to resolve this problem, either by
> removing the features whihc are never going to be implemented (e.g. by
> commenting out the calls) or by marking them as @available(*,unavailable,
> message:"Not available on the Linux platform"). That way, calls that are
> known cannot work can be identified at compile time instead of at run-time.
> I hope we'll then be able to remove the NSUnimplemented calls on the types
> that can never be implemented, so that we can focus on those types and
> functions that we can. Alternatively we can define a different macro, say
> NSUnavailableOnLinux, to indicate that this functionality cannot be present
> (as opposed to just leaving it blank).
> What do you think?
> $ git grep -c NSUnimplemented | sort -n -r -k2 -t:
> Foundation/NSExpression.swift:37
> Foundation/NSURLCache.swift:22
> Foundation/FileManager.swift:22
> Foundation/NSPort.swift:21
> Foundation/NSOrderedSet.swift:20
> Foundation/NSSortDescriptor.swift:19
> ...
> _______________________________________________
> swift-corelibs-dev mailing list
> swift-corelibs-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Ian Partridge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20170728/fc70f80f/attachment.html>

More information about the swift-corelibs-dev mailing list