[swift-corelibs-dev] NSArray.descriptionWithLocale implementation

Documentation says what it checks for item to respond to specific selectors. There are no selectors in Swift, so new implementation should check for protocol conformance instead, I guess. Any ideas? Should new protocol be introduced? Class reference: https://developer.apple.com/library/mac/documen

Re: [swift-corelibs-dev] Defining _GNU_SOURCE for module-map-included headers

Hm. If this is the right setting to set on everybody's system, we could add it as part of Clang initialization (for the Clang inside Swift). Otherwise, you can use "-Xcc" to pass extra flags to Clang, in this case "-Xcc -D_GNU_SOURCE=1". Hope that helps, Jordan > On Dec 20, 2015, at 2:29 , Dmi

Re: [swift-corelibs-dev] NSCoding methods

IMHO on Linux NSKeyedArchiver should always use mangled names. If we want cross-platform archives, we should set up standard substitutions, but given that Swift classes exposed to Objective-C are archived with their full names it doesn't make sense to use "half the name" in the archive. Jordan

Re: [swift-corelibs-dev] Defining _GNU_SOURCE for module-map-included headers

> On Dec 21, 2015, at 9:34 AM, Jordan Rose via swift-corelibs-dev > wrote: > > Hm. If this is the right setting to set on everybody's system, we could add > it as part of Clang initialization (for the Clang inside Swift). Otherwise, > you can use "-Xcc" to pass extra flags to Clang, in this ca

Re: [swift-corelibs-dev] Defining _GNU_SOURCE for module-map-included headers

> On Dec 21, 2015, at 10:57 , Pierre Habouzit wrote: > >> On Dec 21, 2015, at 9:34 AM, Jordan Rose via swift-corelibs-dev >> wrote: >> >> Hm. If this is the right setting to set on everybody's system, we could add >> it as part of Clang initialization (for the Clang inside Swift). Otherwise,

Re: [swift-corelibs-dev] Defining _GNU_SOURCE for module-map-included headers

> On Dec 21, 2015, at 11:00 AM, Jordan Rose wrote: > > >> On Dec 21, 2015, at 10:57 , Pierre Habouzit > > wrote: >> >>> On Dec 21, 2015, at 9:34 AM, Jordan Rose via swift-corelibs-dev >>> mailto:swift-corelibs-dev@swift.org>> wrote: >>> >>> Hm. If this is the right

[swift-corelibs-dev] Inconsistencies between Foundation APIs

I've been working on SR-276 and I'm finding a fair amount of inconsistencies between corelib Foundation and OS X Foundation. It seems to be most common with optionality of return values. e.g., in NSURL corelib: public func URLByAppendingPathComponent(path