4 ms·

> requires full access to source code What do you mean? Editions don't require full access to source code. Rust in general relies heavily on having access to s

> requires full access to source code What do you mean? Editions don't require full access to source code. Rust in general relies heavily on having access to source code, but that has nothing to do with how editions work

zozbot234 7mo ago
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.
pjmlp 7mo ago
Yes they do, when mixing crates from various editions and how changes interact together.
- aw1621107 7mo ago
  > 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.
  - pjmlp 7mo ago
    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.
    - Rusky 7mo ago
      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.
      - pjmlp 7mo ago
        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
        ChrisSD 7mo ago
        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.
        pjmlp 7mo ago
        What I am stuck is Rust folks advocating editions as the solution for everything in language evolution, when it clearly isn't.
    - aw1621107 7mo ago
      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.
      - pjmlp 7mo ago
        Exactly because they don't allow it, they don't cover all scenarios regarding language evolution

zozbot234 7mo ago

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.

pjmlp 7mo ago

Yes they do, when mixing crates from various editions and how changes interact together.

aw1621107 7mo ago
> 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.
- pjmlp 7mo ago
  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.
  - Rusky 7mo ago
    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.
    - pjmlp 7mo ago
      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
      - ChrisSD 7mo ago
        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.
        pjmlp 7mo ago
        What I am stuck is Rust folks advocating editions as the solution for everything in language evolution, when it clearly isn't.
  - aw1621107 7mo ago
    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.
    - pjmlp 7mo ago
      Exactly because they don't allow it, they don't cover all scenarios regarding language evolution