Defining the Rust 2024 edition

That's not the same issue I was raising, though. I *absolutely* think that you should consider every part of your public ABI with care. However, that does *not* mean I want every public ABI to have to use raw pointers, eschew things like Option and Result and String and Vec and HashMap, be unable to provide objects that have methods, be unable to accept parameters that can be anything-that-implements-a-trait, and many many other features.

crabi will solve some of this for cross-language ABIs, and there's another effort to provide a much broader stable ABI surface that's just for Rust-to-Rust calls, but in both cases it'll take a while before we get there. And in the meantime, I don't think it's reasonable to require that people provide a C-only ABI just so it can be a shared library; that'd be a substantial step backwards.