> On Oct 5, 2016, at 7:08 PM, Greg Parker <[email protected]> wrote:
>
>> 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.
>
> 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.
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.
As for handing unsupported features, I'd like you to be able to say something
like (using a version of today's syntax):
import Platform
import func CPlatform.newfunc(_:_:)
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.)
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
