Great, sounds good. If you ever notice a divergence, feel free to either file a bug or submit a PR that adds the comment. I don’t want to lose track of these things.
- Tony > On Jan 4, 2016, at 11:55 AM, Ian Ynda-Hummel <iany...@gmail.com> wrote: > > Got it. I've seen the experimental thing elsewhere in the code. I'll work > under the assumption that inconsistencies are experimental and I'll open bugs > for things that are inconsistent but not marked as such. > > On Mon, Jan 4, 2016 at 2:51 PM Tony Parker <anthony.par...@apple.com > <mailto:anthony.par...@apple.com>> wrote: > Hi Ian, > > Any place where the API differs should be marked with a comment like this: > > /// - Experiment: This is a draft API currently under consideration for > official import into Foundation > > If not, then we found some place that we either need to change or propose a > change for. We can track those with bugs on bugs.swift.org > <http://bugs.swift.org/>. Most of the ‘Experiment’ APIs are something we have > no alternative but to change, though. > > Thanks for your work on this, > - Tony > > >> On Dec 21, 2015, at 5:39 PM, Ian Ynda-Hummel via swift-corelibs-dev >> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote: >> > >> I've been working on SR-276 <https://bugs.swift.org/browse/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(pathComponent: String) -> NSURL? >> >> OS X: >> public func URLByAppendingPathComponent(pathComponent: String) -> NSURL >> >> That particular case seems to be a difference in the treatment of the return >> value from CFURL >> >> public func CFURLCreateCopyAppendingPathComponent(allocator: >> CFAllocator!, _ url: CFURL!, _ pathComponent: CFString!, _ isDirectory: >> Bool) -> CFURL! >> >> Which briefly looking appears to be the same between corelib and OS X. >> >> I'm not sure what the best way forward on these things is, though, as the >> corelib versions have seemed consistently improved, but presumably we still >> want maintain compatibility. Anyone have ideas? > >> _______________________________________________ >> 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> >
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
