I mean, the almost-simplest abstraction possible the std::vector has potential UB right in its [] operator. Sure, you could theoretically always do "at(...)", but good look convincing anybody else on to use this safer, yet more verbose and "slower" alternative to [].
There are lots of these things in the STL. (For trickier things, see iterator invalidation, etc.)
A lot of the unsafety is also baked into basic language primitives, e.g. dangling references/pointers because of confusion around lifetime, etc., etc.
There's just sooooo much that you have to get 100% right as a programmer and adding abstractions (while a definite improvement in many cases, e.g. smart pointers) hasn't proven to be nearly enough.
It's your responsibility to pass the allowed range of value to a function. It a function description tells you to e.g. pass only non-null pointers or only even integers then it's your fault if you don't do it. Inside the function there may me asserts but there is no need to such checks in general.
There's just sooooo much that you have to get 100% right as a programmer > It's simply the job of the programmer to get it 100% right. No language can do this job for you.
EDIT: The fundamental problem with the "attitude" of C++ I see is that fast-and-potentially-UB by default is a bad default (as almost all defaults in C++ are). It would be far saner to have slow-but-guaranteed-behavior by default[0]... but the C++ committee has repeatedly demonstrated that they're not willing to do that. Well, it's either that or require the compiler to prove that the fast behavior is safe (an example of which is Rust), but that's likely not feasible in C++... unless you turn it into Rust with even more obscure and verbose annotation.
[0] At least you can stay safe and then optimize as needed from there.
Sure we all don't get it right 100% on the first write. For this reason we test and iterate. Equally you could say that it is pure hubris that a language will enable you to make your code right 100% of the time.
You mean the vector::operator[] is an example of fast-and-potentially-UB ? I don't see any UB if the constraints are met (keeping the index within valid range).
If they are not willing in a specific case they for sure had specific reasons not to be.
> You mean the vector::operator[] is an example of fast-and-potentially-UB ? I don't see any UB if the constraints are met (keeping the index within valid range).
I don't understand this line of reasoning when it's plain that the contraints are not met. Routinely. It happens all the time. Again, see the CVEs.
This. It looks like a blatant attempt to ride the coattails of C++, which oddly enough is not the first case coming from Redmond (see C++/CX).
If the concept is able to fly on its own without these marketing crutches then it would be more credible to just claim it's a successor.
> C++ has this issue of every few years looking entirely different So what. The style you have been using does the job then just keep it. There is no obligation switch to use new stuff. You should stick with that what proved to be successful.
Modern languages use a type of syntax where all declarations start with an introducer, something along the lines of "let", "fn", "class", etc... in order to eliminate ambiguities as well as avoid the need for the parser to have potentially unbounded look-ahead.
int x = 5;
auto x = 5;
let x: i32 = 5;
let x = 5;
It reminds me of what Google did with AngularJS and Angular. It is dishonest on its face and turns me off toward listening further.
C++ has this issue of every few years looking entirely different. There's no long-lasting thought about how changes or additions to the language will echo into perpetuity.
I do not know the totality of what issues we face when working with C++ (or C) outside of say, bounds safety, optimization issues that cause undefined behavior, and implicit conversion problems, but I do have a feeling that every time I see safety issues in C++ (or C) they can almost always be addressed by using an already existing safe alternative, asking whether or not a supposed "valid" optimization should be considered valid if in combination with another optimization it causes undefined behavior, or creating library functions which assist with converting what would otherwise be implicit type conversions to explicit with error checking.