<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 5, 2016 at 6:14 PM, David Waite 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">If we are pulling in functions/structures not defined by the C standard library or by POSIX, I’d be reluctant to support a standard name. It would be troublesome if someone thought that they were cross-platform but turned out to use strfry() heavily<br>
<br>
I certainly wonder what people specifically want to bring the C standard library or POSIX libraries in for - is it compatibility with third party libraries? Functionality missing in Foundation?<br></blockquote><div><br></div><div>To throw one use case out there, it's used extensively in corelibs-foundation itself.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-DW<br>
<div class="HOEnZb"><div class="h5"><br>
> On Oct 5, 2016, at 4:57 PM, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
>> On Sep 13, 2016, at 12:29 PM, Brian Gesiak via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>> I hadn't thought about a unified overlay for POSIX. I think the simplified import alone has benefit to warrant its own evolution proposal. Would it be possible to have a separate discussion for the POSIX overlay idea? Or is there a reason that I'm missing that prevents the import from being viable on its own? (Apologies in advance if there's an obvious answer to this question!)<br>
><br>
> I've heard the argument before that we should do a full overlay, but I think this is becoming a case of the perfect being the enemy of the good. Having some sort of "just import whatever the system libc is called" module would be a significant improvement in practice over the state of the art, even if we don't do any other adaptation.<br>
><br>
> Here's what I would suggest. We have a convention for exposing "raw" imports of C libraries: you call them `C\(libraryName)`. So I would suggest we introduce a `CLibc` module which provides a raw import of the system's libc. If we later decide to do a full-featured overlay, that's great—we can call it `Libc`. But `CLibc` by itself would be an improvement over the status quo and a step in the right direction.<br>
><br>
> --<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>
<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>