What I think you’re touching on is the idea of public/private dependencies that @wycats and I have been intending to write an RFC about for some time now. There’s a notion of a public dependency, one which is exported through your API, and a private dependency, one which is purely internal. Obviously if you change an API you need a new major version, and consequently it should be obvious that if you upgrade a major version of a public dependency that you just changed your API and therefore need a new major version as well. Private dependencies can be upgraded/duplicated whenever as they’re not part of your public interface.
This is not currently implemented in Cargo but it’s the essential principle that the community needs to follow. We hope to provide tools to help with this, but that’s how I believe we should be framing this discussion of moving types to libc. So along those lines…
The point I’m getting at is that this is not wrong at all so long as it’s done properly. This is essentially having a public dependency which is a serious API commitment on behalf of a crate, and it’s just unfortunately not clear today that this is happening.
Making a blanket statement that essentially all dependencies should be private dependencies is unfortunately a non-starter for an ecosystem.
Otherwise yes, the problem is that there are multiple definitions of
c_void, and my claim is that it doesn’t matter whether it’s in core, std, or libc so long as it’s only in one. If we have to make a choice then the libs team currently prefers libc as the location for
c_void and we’d deprecate the definition in libstd.
This is correct! Following this logic, however, we should put everything in the standard library which we certainly don’t want to do. The real conclusion to draw here is that public dependencies need to be very stable very quickly. Due to the need for all crates to agree on versions, upgrading does indeed cause a lot of breakage (see the points about public dependencies above).
This is why the libs team invested in the
libc crate early on after 1.0 and have now migrated the crate to the first official
rust-lang crate. This crate is the foundation for any and all FFI and needs to be stable essentially immediately, which is what we’ve now done.
The rest of your comment and thoughts are indeed correct, but in the interest of staying focused on libc I don’t think we have to worry much. We’ve vetted a design for libc 1.0, we’re just waiting for the right moment to release 1.0, and we most certainly understand the cost of a 2.0.
I think it’d be useful to shy away from “problems at large” in the ecosystem today and continue to remain focused on libc and where
c_void is going to be located. Otherwise we may derail ourselves easily!
As far as I know these cases are very few and far between. I would much rather invest effort and cognitive thought into rectifying this situation rather than view it as a reason for why these types should be pushed into core, no less.