Seems to be a similiar problem field as writing blocking functions that call async functions in C# and co-existence of synchronous and asynchronous code.
> why people literally do not and cannot get it right 100% of the time. Thinking so is pure hubris.
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.
I think it would be more constructive to propose a constrained subset, get rid of legacy, propose default behaviours for parts that are undefined and so on. Stuff that does not belong to this subset can still be used within an unconstrained clause.
If I read e.g. "Why build Carbon?" on https://github.com/carbon-language/carbon-lang I dont find any concrete reasons or proves that show why C++ should be abandoned for something completely new but somehow very similar. There are so many question around the actual language definition like who maintains it, how is the standardization process. Who will adapt to it or to something else. ... This seems all so utopic.
I have been using C++ for many years with fantastic success. It allows me to create all I want/need from embedded to high performance projects.
That you may shot you in the foot is in fact not bad. It compels you to be careful and think deeply about the design and only use what you completely understand.
With other languages your program might not crash but probably will do wrong things like eat up memory or access still references outdated data. You will find error much later in the process when it costs multiple magnitudes more.
Syntax is mostly a matter of taste. Preference of taste and style changes with time and trends. Why should "let name : type" be preferred to "type name"? Just because others do it? Why and this unnecessary, additional ':'?
> 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.
> I mean, the almost-simplest abstraction possible the std::vector has potential UB right in its [] operator.
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.
There are numerous recommendations such as
https://learn.microsoft.com/en-us/archive/msdn-magazine/2015...
Final phase is "I hope these techniques will help you adopt async into your existing applications in a way that works best for you."