"Modern C++" versus "older-style C++" is a meaningless, hand-wavey distinction: if your toolchain accepts "older-style C++" then you're using a vulnerable language; if your toolchain rejects "older-style C++" (e.g. using lint rules) then you're not programming in C++, you're using a safer language which just-so-happens to be a subset of C++. That doesn't affect how vulnerable the C++ language is.
If you're not using every possible construct in unsafe rust blocks, then you're not using rust - just a safer language that just-so-happens to be a subset of rust.
The difference is that "discouragement" is in the compiler itself not external lint tools (though many of those "lint tools" are just optional arguments to the compiler). The big difference is the general community having less of a spread of opinions on what the recommended subset is, not helped by that changing over the age of the language, and not being clear about what the general epoch of the language are to highlight things that may be generally replaces by a better construct. Honestly, I'd say the biggest failing of the C++ updates today are lacking some similar epoch system - where older constructs can actually be deprecated from the language.
It would be interesting to see if rust gets exactly the same thing as the community expands, and accumulating language updates affect the generally accepted best practices. It's clear Rust doesn't intend to be completely static, with significant language features being added every version. I wonder if one day we'll look at today's rust in the same way as someone focused on "modern" c++ looks at c++98 C-with-classes style code.
Everyone uses a subset of any language, that's what coding styles and common patterns are. A definition of this subset is a really useful thing you can do for any non-trivial project IMHO, for any language.
> If you're not using every possible construct in unsafe rust blocks, then you're not using rust - just a safer language that just-so-happens to be a subset of rust.
You seem to have misunderstood my point. Whether or not you (or I) happen to be using this or feature of a language is irrelevant; the question is whether it's valid input to the toolchain.
For comparison, the existence of an SQL injection vulnerability in example.com has nothing to do with whether you or I happen to exploit that vulnerability or not.
W.r.t. Rust: the mere existence of "safe" and "unsafe" subsets, which (a) can be explicitly permitted or forbidden, and (b) are well-defined and don't differ from person to person, org to org, etc. makes it much more practical to forbid "unsafe" from as much of our code as possible, and to pin-down precisely those locations where it has been used. The same cannot be said for e.g. "modern C++"
