<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 5, 2016, at 6:38 PM, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div class=""><br class="">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.</div></div></blockquote><br class=""></div><div><div>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.</div><div class=""><br class=""></div></div><div><br class=""></div><div>-- </div><div>Greg Parker <a href="mailto:gparker@apple.com" class="">gparker@apple.com</a> Runtime Wrangler</div><div><br class=""></div><div><br class=""></div></body></html>