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 current API is unsuitable for Swift in various ways. - Tony > On Jul 28, 2017, at 7:27 AM, Ian Partridge via swift-corelibs-dev > <swift-corelibs-dev@swift.org> wrote: > > 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 <mailto: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 > <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 <mailto:swift-corelibs-dev@swift.org> > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev > <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
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
