<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Dec 3, 2015 at 2:13 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
As others have surmised, the goal for the Swift Foundation project is to provide a pure-swift implementation (which reuses widely-available C libraries) of important Foundation APIs that do *not* depend on the Objective-C runtime. Reusing GNUstep, Cocotron, or even Apple’s existing Foundation implementation didn’t allow us to achieve those goals, so we didn’t go with those approaches.<br></blockquote><div><br></div><div>This is great, but is the goal also to exactly duplicate all the idiosyncrasies of the Obj-C Foundation?</div><div><br></div><div>Quiz: what's the result of <span class="">NSURL</span><span class="">(string: </span><span class="">"<a href="http://one/two;three/four">http://one/two;three/four</a>"</span><span class="">)?.</span><span class="">URLByAppendingPathComponent</span><span class="">(</span><span class="">"five"</span><span class="">)</span> ?</div><div><br></div><div>If, as I would hope, corelibs-foundation is an opportunity to make simpler APIs that resolve some of these weirdnesses, then should the class names (NSURL, NSFileHandle, etc.) really be the same?</div><div><br></div></div></div></div>