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

[Ian Partridge]

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
NSProbablyNever().

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.

Regards,
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>