4 ms·

But there's no concept of safety, lifetime and borrows in C++ (there's aliasing, but the rules are different). There's a lot of code that one could write that's

• rumanator 6y ago
  > There's a lot of code that one could write that's perfectly kosher in C++ but a no-no in Rust. Not a problem. Rust checks are applied to the Rust code you write or import, and everything else is just ingested as is.
• Ygg2 6y ago
  So, Rust is to blame for C++ problems? No. C++ programs are safe under certain conditions. If they aren't then they need to be changed in C++ or in Rust interfacing code. Even if something is unsafe, it can still be used safely.
  • fluffything 6y ago
    Sure, but safe Rust functions can _always_ be used safely. If your function cannot always be used safely, either it is an `unsafe` Rust function, or your program is broken according to the Rust spec. Publishing safe Rust APIs that are _intentionally_ unsound should at best be warned about to any other crate that depends on it. Ideally, those authors and their crate would simply be banned.
    • Ygg2 6y ago
      And I explained. Either you change the C++ lib to not behave unsafely for inputs. Or you manually change the binding to keep the invariant. The assumption behind linking to C++ code is that it doesn't contain unsoundness. If it does the library was fucked way before.
      • fluffything 6y ago
        I agree with you. But this discussion is about a tool that: * does not change the C++ code to behave correctly for all inputs * does not (and technically cannot) generate safe Rust bindings that keep the invariant (the bindings are automatically generated under the assumption that all C++ code is safe for all inputs).
        • the_mitsuhiko 6y ago
          It seems it’s quite an absolutist way to look at safety. It establishes that nothing is allowed to ask a user to proof safety unless the unsafe keyword is used somewhere. I think this is already invalidated by countless code generation and build scripts.
          • Jweb_Guru 6y ago
            The use of the unsafe keyword is how Rust's "absolutist" view is made practical... the obligation to write an extra seven to nine characters is pretty minimal compared to the burden of an actual proof. "Some automated build script probably don't respect that" isn't a great argument against that standard, I think, especially with the push to sandbox build scripts and procedural macros showing that people are still quite concerned about safety in those areas (I know you're referring to the code they generate and not the scripts themselves, but I see these as related issues of trust).
            • Ygg2 6y ago
              But the thing is, unsafe was never absolutist. Even regular safe Rust assumes you use unsafe in a proper manner. This build tool assumes your C++ code is safe enough to wrap around unsafe trivially.
              • Jweb_Guru 6y ago
                Regular Rust assumes that you use unsafe in a proper manner, but still asks you to mark functions that can cause memory unsafety with the wrong inputs as unsafe. This is so people know what code to audit. If you don't do this (or at least, mark something in the module as unsafe), it's considered a bug in your library. Among other things, this kind of clear isolation boundary makes it obvious where your proof obligations are and consequently which code you can ignore when debugging undefined behavior (code outside the unsafe module is not responsible for the unsafety no matter what weird input it provides). This build tool, as first proposed, knowingly exposed macros that can cause memory unsafety with the wrong inputs, without making you write unsafe. If a build tool makes assumptions like "you probably know what you're doing with that C++ code" without asking you to write unsafe, it is just as wrong as an implementation of unchecked indexing that wasn't marked unsafe (because "you'll probably know not to use this unless you're really in bounds."). It is clear that you consider this a trivial matter, but many people very heavily involved in the Rust community (including the people working on its soundness proofs) do not.
  • simias 6y ago
    > C++ programs are safe under certain conditions. I entirely agree with this. My point is that these conditions are not always (and often aren't) encoded in the C++ syntax itself, and are instead part of the documentation or some softer coding convention. As such an automatic code converter can't be aware of these details and can't decide if a call is safe or not. C++ doesn't have the concept of safety built in, it's the programmer that's in charge of keeping track of the soundness of it all. It's not enforced by the compiler like Rust does. I'm really surprised that there's so much debate around this in this thread honestly (including by people who know Rust very well). That's blindingly obvious to me that it's a very bad idea. Clearly that means that I'm missing one side of this issue.
    • cle 6y ago
      I’m not surprised at all. If you follow the Rust community, this is an endless debate. It’s totally off-putting to me and makes me want to avoid the language altogether.
• deleted 6y ago
  [deleted]