<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">- Tony<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 28, 2017, at 7:27 AM, Ian Partridge via swift-corelibs-dev &lt;<a href="mailto:swift-corelibs-dev@swift.org" class="">swift-corelibs-dev@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Hi Al, thanks for bringing this up.</div><div class=""><br class=""></div><div class="">My view is that we shouldn't have API in the project which is never going to be implemented.&nbsp; 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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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().</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Regards,</div><div class="">Ian Partridge<br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On 28 July 2017 at 15:07, Alex Blewitt via swift-corelibs-dev <span dir="ltr" class="">&lt;<a href="mailto:swift-corelibs-dev@swift.org" target="_blank" class="">swift-corelibs-dev@swift.org</a>&gt;</span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class="">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:<div class=""><br class=""></div><div class=""><a href="https://github.com/apple/swift-corelibs-foundation/pull/1140" target="_blank" class="">https://github.com/apple/<wbr class="">swift-corelibs-foundation/<wbr class="">pull/1140</a></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class="">What do you think?</div><div class=""><br class=""></div><div class=""><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255)" class=""><span style="font-variant-ligatures:no-common-ligatures" class="">$ git grep -c NSUnimplemented | sort -n -r -k2 -t:</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255)" class=""><span style="font-variant-ligatures:no-common-ligatures" class="">Foundation/NSExpression.swift:<wbr class="">37</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255)" class=""><span style="font-variant-ligatures:no-common-ligatures" class="">Foundation/NSURLCache.swift:22</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255)" class=""><span style="font-variant-ligatures:no-common-ligatures" class="">Foundation/FileManager.swift:<wbr class="">22</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255)" class=""><span style="font-variant-ligatures:no-common-ligatures" class="">Foundation/NSPort.swift:21</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255)" class=""><span style="font-variant-ligatures:no-common-ligatures" class="">Foundation/NSOrderedSet.swift:<wbr class="">20</span></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255)" class=""><span style="font-variant-ligatures:no-common-ligatures" class="">Foundation/NSSortDescriptor.<wbr class="">swift:19</span></div></div><div style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255)" class=""><span style="font-variant-ligatures:no-common-ligatures" class="">...</span></div></div><br class="">______________________________<wbr class="">_________________<br class="">
swift-corelibs-dev mailing list<br class="">
<a href="mailto:swift-corelibs-dev@swift.org" class="">swift-corelibs-dev@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-corelibs-dev" rel="noreferrer" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">corelibs-dev</a><br class="">
<br class=""></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature">Ian Partridge<br class=""></div>
</div></div></div>
_______________________________________________<br class="">swift-corelibs-dev mailing list<br class=""><a href="mailto:swift-corelibs-dev@swift.org" class="">swift-corelibs-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-corelibs-dev<br class=""></div></blockquote></div><br class=""></div></body></html>