6 ms·

At the least, it's failed to pique Linus's interest. He's re-affirmed his disinterest in C++ in this mailing thread again[1]: > You'd have to get rid of some

At the least, it's failed to pique Linus's interest. He's re-affirmed his disinterest in C++ in this mailing thread again[1]: > You'd have to get rid of some of the complete garbage from C++ for it to be usable. > One of the trivial ones is "new" - not only is it a horribly stupid namespace violation, but it depends on exception handling that isn't viable for the kernel, so it's a namespace violation that has no upsides, only downsides. > Could we fix it with some kind of "-Dnew=New" trickery? Yes, but considering all the other issues, it's just not worth the pain. C++ is simply not a good language. It doesn't fix any of the fundamental issues in C (ie no actual safety), and instead it introduces a lot of new problems due to bad designs. [1] https://lore.kernel.org/ksummit/CAHk-=wiwZWAo_Ki587FD2BrAQVK71TBN=uKimdBf1Pxg3=+nTw@mail.gmail.com/ https://lore.kernel.org/ksummit/CAHk-=wiwZWAo_Ki587FD2BrAQVK...

tialaramex 5y ago
The exception handling thing is a showstopper. Stroustrup is resolute that C++ style exception handling is the right error model. So even if a big fraction of C++ programmers disagree, the ISO C++ language standard, and the guidance for new developers, is going to keep saying Exceptions are the way forward for the foreseeable future. Linus didn't like the panic-on-fail memory allocation handling from userspace Rust for the same reason and so the kernel Rust people had to be very clear early on that was temporary and wouldn't survive from a prototype into the actual kernel. There are some edge cases where this is surprising and I expect Linus will ask for further work. e.g. let x = "Clowns".to_owned(); let mut y = x + " are not welcome here"; y += " any more."; The first variable ends up with a growable String, containing the word "Clowns" so that's an allocation and it might fail, in userspace it panics, in kernel Rust should this not compile? If it needs to "return an error" how? The second line needs a concatenation operation, it won't end up with a new String, the old one gets moved instead (in Rust this means if you try to refer to x after this that won't compile, it was moved and the compiler knows that) but it also gets a concatenation to add this extra string to the end, probably allocating again. Thus it too might fail, in userspace that would panic, but in the kernel what happens this time? Does this Add operator have a Result type now? The third line concatenates again, but this time the operation doesn't even have a return type, it's obliged to mutate y, so there is just no possible way it can result in an error. Either this mustn't happen in the Linux kernel, or it panics when it can't allocate. Whereas these are all fine, they don't allocate and aren't writeable so they won't bother Linus: let x = "Clowns"; // A str, definitely UTF-8 encoded let y = b"\xf7\xf7\xf7"; // not Unicode, just some bytes let z = r#"No need to "escape" the double quotes now."#;
- forrestthewoods 5y ago
  > Does this Add operator have a Result type now? I suspect the answer is: those traits not implemented for String in no-panic mode. And instead you have to use fallible “try_extend” methods that return a result? I’m just guessing though.
  - db48x 5y ago
    This is usually the right way to go. If you cannot implement the exact trait then you make a trait of your own with similar semantics instead. This one is a language item though, which complicates things.
    - Ericson2314 5y ago
      Yeah, first we just nuke a bunch of impls, then we figure out whether we need new infra like a TryClone or whatever.
    - Measter 5y ago
      To clear something up here, while the Add trait is a language item, String is not. The String type is just a normal type implemented in liballoc[0]. As far as the language is concerned, there's nothing separating it from any other random type a user might write[1]. If you're in a no_std environment, String doesn't even exist unless you depend on liballoc. The reason you can use String with the + and += operators is because it implements the Add and AddAssign traits[2], and it looks like the implementations are already feature gated for OOM handling so might not be implemented for String. [0] https://github.com/rust-lang/rust/blob/master/library/alloc/src/string.rs#L289-L294 https://github.com/rust-lang/rust/blob/master/library/alloc/... [1] Note that the compiler knows about it to provide better diagnostics to the user, but this has no impact on the language itself. [2] https://github.com/rust-lang/rust/blob/master/library/alloc/src/string.rs#L2175-L2185 https://github.com/rust-lang/rust/blob/master/library/alloc/...
      - db48x 5y ago
        Yes, that’s a good point. I suppose the compiler can parse «foo + "bar"» regardless of whether the Add language item is implemented for the types involved. It’ll only fail during type checking, which is a later step. Not so complex after all. Oh, and good point about the existing feature gate; I debated going and looking to see if one existed yet or not, but I was hungry so I didn’t. Glad you were around to point it out.

tialaramex 5y ago

The exception handling thing is a showstopper. Stroustrup is resolute that C++ style exception handling is the right error model. So even if a big fraction of C++ programmers disagree, the ISO C++ language standard, and the guidance for new developers, is going to keep saying Exceptions are the way forward for the foreseeable future. Linus didn't like the panic-on-fail memory allocation handling from userspace Rust for the same reason and so the kernel Rust people had to be very clear early on that was temporary and wouldn't survive from a prototype into the actual kernel. There are some edge cases where this is surprising and I expect Linus will ask for further work. e.g. let x = "Clowns".to_owned(); let mut y = x + " are not welcome here"; y += " any more."; The first variable ends up with a growable String, containing the word "Clowns" so that's an allocation and it might fail, in userspace it panics, in kernel Rust should this not compile? If it needs to "return an error" how? The second line needs a concatenation operation, it won't end up with a new String, the old one gets moved instead (in Rust this means if you try to refer to x after this that won't compile, it was moved and the compiler knows that) but it also gets a concatenation to add this extra string to the end, probably allocating again. Thus it too might fail, in userspace that would panic, but in the kernel what happens this time? Does this Add operator have a Result type now? The third line concatenates again, but this time the operation doesn't even have a return type, it's obliged to mutate y, so there is just no possible way it can result in an error. Either this mustn't happen in the Linux kernel, or it panics when it can't allocate. Whereas these are all fine, they don't allocate and aren't writeable so they won't bother Linus: let x = "Clowns"; // A str, definitely UTF-8 encoded let y = b"\xf7\xf7\xf7"; // not Unicode, just some bytes let z = r#"No need to "escape" the double quotes now."#;

forrestthewoods 5y ago
> Does this Add operator have a Result type now? I suspect the answer is: those traits not implemented for String in no-panic mode. And instead you have to use fallible “try_extend” methods that return a result? I’m just guessing though.
- db48x 5y ago
  This is usually the right way to go. If you cannot implement the exact trait then you make a trait of your own with similar semantics instead. This one is a language item though, which complicates things.
  - Ericson2314 5y ago
    Yeah, first we just nuke a bunch of impls, then we figure out whether we need new infra like a TryClone or whatever.
  - Measter 5y ago
    To clear something up here, while the Add trait is a language item, String is not. The String type is just a normal type implemented in liballoc[0]. As far as the language is concerned, there's nothing separating it from any other random type a user might write[1]. If you're in a no_std environment, String doesn't even exist unless you depend on liballoc. The reason you can use String with the + and += operators is because it implements the Add and AddAssign traits[2], and it looks like the implementations are already feature gated for OOM handling so might not be implemented for String. [0] https://github.com/rust-lang/rust/blob/master/library/alloc/src/string.rs#L289-L294 https://github.com/rust-lang/rust/blob/master/library/alloc/... [1] Note that the compiler knows about it to provide better diagnostics to the user, but this has no impact on the language itself. [2] https://github.com/rust-lang/rust/blob/master/library/alloc/src/string.rs#L2175-L2185 https://github.com/rust-lang/rust/blob/master/library/alloc/...
    - db48x 5y ago
      Yes, that’s a good point. I suppose the compiler can parse «foo + "bar"» regardless of whether the Add language item is implemented for the types involved. It’ll only fail during type checking, which is a later step. Not so complex after all. Oh, and good point about the existing feature gate; I debated going and looking to see if one existed yet or not, but I was hungry so I didn’t. Glad you were around to point it out.