> it's doubtful that anything meaningful can be achieved when "undefined behavior" remains an acceptable definition of the semantics of an operation.

Well, I should be fair. I may be wrong here, but my understanding of ISO Core C++ plus all safety profiles is that this will no longer be the case: there will be no undefined behavior in this particular dialect of C++, assuming the effort to create this dialect succeeds.

Yeah, that's my understanding as well... but I'm skeptical that this is actually possible (within reason) given the history of C++ and the sheer weight of legacy C++ code bases.

Few useful codebases are brand new. Or if they are they don't stay new. Weight accumulates and at some point efforts always shift to successfully iterating existing things of value.

Which is the problem with the massive subsetting of the language that ISO Core C++ with all safety profiles turned on performs. It rules out so much existing code that porting will be very expensive.

We won't know what the delta is between "migrating to ISO Core C++ with all safety profiles" and "migrating to another, memory-safe language with a good FFI" until ISO Core C++ is complete and widely deployed. My instinct tells me that this delta will not be particularly wide--that is, that porting most existing industry C++ code to totally safe ISO Core C++ will not be much easier than rewriting that code in Go or Swift or whatever. (Look at how long the Python 2 to Python 3 transition has been, and consider that ISO Core C++ is much farther away from industry C++ than Python 3 was from Python 2.)

I could be wrong about this, though--we'll have to see.

Sure... and that's kind of what I'm both skeptical of (and intrigued by).

I'm just waiting for standards-sanctioned A(lgebraic)DT data type support -- it's bound to happen at some point! :)