<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 5, 2016 at 10:47 PM, Brent Royal-Gordon via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> On Oct 5, 2016, at 7:08 PM, Greg Parker <<a href="mailto:gparker@apple.com">gparker@apple.com</a>> wrote:<br>
><br>
>> Now, as for naming: I like using the leading "C" convention ("CLibc") because it leaves us room for introducing an overlaid version of the module in the future without breaking source compatibility. Because of this, I wouldn't want to name the module just `C`, because it wouldn't leave room for a Swifty version later.<br>
><br>
> I don't think separating the raw C library translation from the pretty Swift wrapper works, at least not for everybody. The problem is that the raw translation is going to have functions that the pretty wrapper does not. (Perhaps the pretty wrapper is new and incomplete. Perhaps an OS has added functions and the pretty wrapper has not caught up yet.) If you try to import both then you end up with the same problems of name collisions today and source incompatibility in the future when the pretty wrapper grows.<br>
<br>
</span>I didn't mean that you could import both—merely that, if you used CLibc (or CPlatform) today, the introduction of the pretty Libc or Platform in a future version of Swift wouldn't affect your existing code.<br>
<br>
As for handing unsupported features, I'd like you to be able to say something like (using a version of today's syntax):<br>
<br>
import Platform<br>
import func CPlatform.newfunc(_:_:)<br>
<br>
Which would hopefully mean that, if a future version of Libc added newfunc(_:_:), the CLibc version—which is the one we explicitly requested—would shadow it. (Perhaps when you rebuilt against the newer version of Libc, you'd get a shadowing warning that would hint to you that you don't need to pull that function in from CLibc anymore.)<br></blockquote><div><br></div><div>See, I'd assumed that the "unified" Darwin/Glibc would simply be what you call Platform. And if we're going to have that overlay, what's the point of also renaming Darwin/Glibc to CPlatform, given that it's going to be different between platforms, and given that what's not going to be in the Platform overlay is much more likely to be the divergent bits?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</div></div></blockquote></div><br></div></div>