On 28 Jul 2017, at 19:44, Tony Parker <anthony.par...@apple.com> 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. > NSSortDescriptor, NSExpression), but it does seem clear at this point that > the current API is unsuitable for Swift in various ways.
Perhaps if more dynamic introspection lands in a future version of Swift they might make sense. It's also possible that some of the new keypath stuff being added in Swift might make a good potential API in future, so maybe those aren't quite as cut and dry. In the meantime I'll take a stab next week at proposing some unavailability annotations for some of the stuff which almost certainly doesn't make sense, to do with Mach ports and NSZone. Alex > > - 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> 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 >
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
