upvote

points

by SkiFire131 days ago |
comments
upvoteby zozbot2341 days ago|
next
[-]
You can write a binary library that exposes a C ABI using Rust (which is indistinguishable from an ordinary C/C++ library) and then provide source for a Rust wrapper crate that provides a "safe" interface to it, much like a C header file.
reply
upvoteby pjmlp1 days ago|
prev|
[-]
Yes they do, when mixing crates from various editions and how changes interact together.
reply
upvoteby aw162110722 hours ago|
parent|
[-]
> when mixing crates from various editions and how changes interact together.

Could you elaborate more on this? It's not obvious to me right now why (for example) Crate A using the 2024 edition and Crate B using the 2015 edition would require both full access to both crates' source beyond the standard lack of a stable ABI.

reply
upvoteby pjmlp19 hours ago|
parent|
[-]
Because in order to have standard library breaking changes across editions, if those types are exposed in the crate public types, or change their semantics across editions, the compiler has to be able to translate between them when generating code.

See the Rust documentation on what editions are allowed to change, and the advanced migration guide on examples regarding manual code migration.

Not so much what has happened thus far, rather the limitations imposed in what is possible to actually break across editions.

reply
upvoteby Rusky18 hours ago|
parent|
next
[-]
Or put another way, a hypothetical feature that you made up in your head is the thing that requires source access. Editions do not let you change the semantics of types.

To be fair, Rust tooling does tend toward build-from-source. But this is for completely different reasons than the edition system: if you had a way to build a crate and then feed the binary into builds by future compilers, it would require zero additional work to link it into a crate using a different edition.

reply
upvoteby pjmlp15 hours ago|
parent|
[-]
Exactly, hence why people should stop talking about editions as if they sort out all Rust evolution problems, in your own words it doesn't allow changing type semantics
reply
upvoteby ChrisSD14 hours ago|
parent|
[-]
I think you're too stuck on the current implementation. Work is going into investigating how to evolve the standard library over editions. The "easiest" win would be to have a way to do edition-dependent re-exports of types.
reply
upvoteby pjmlp4 hours ago|
parent|
[-]
What I am stuck is Rust folks advocating editions as the solution for everything in language evolution, when it clearly isn't.
reply
upvoteby aw162110717 hours ago|
parent|
prev|
[-]
What you're describing sounds more like a potential issue with editions if/when they allow breaking stdlib changes more than a problem with editions as they exist today, which is more what I took the original comment to be talking about.
reply
upvoteby pjmlp15 hours ago|
parent|
[-]
Exactly because they don't allow it, they don't cover all scenarios regarding language evolution
reply
upvoteby aw162110714 hours ago|
parent|
[-]
OK, sure, but again what breaking changes editions do/don't currently allow is independent from what SkiFire13/I was responding to, which was the "requires full access to source code" bit.
reply
upvoteby pjmlp4 hours ago|
parent|
[-]
How do you expect a compiler to be able to mix and match changes across editions between crates, if those happen to be changes in semantic behaviour?
reply
upvoteby aw16211074 minutes ago|
parent|
[-]
Depends on the change. Obviously the compiler doesn't need to care about cross-edition compatibility between crates if the changes in question don't impact the public API. Otherwise, I'd expect the compiler to canonicalize the changes, and from what I understand that is precisely how edition changes are chosen/designed/implemented.
reply