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@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev > > -- Ian Partridge
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
