> To be clear, this is "forever" I guess I didn't finish my thought in that comment, because it isn't forever... it's only until either the C++ is gone, or the

> To be clear, this is "forever" I guess I didn't finish my thought in that comment, because it isn't forever... it's only until either the C++ is gone, or the Rust language has developed an equally acceptable alternative (which could be upstreamed by Google, or come from somewhere else). And realistically, the C++ would never have to go away entirely for this UB handling fork to become unnecessary, depending on the driving factors. Some code paths are more performance sensitive than others, and these tend to represent a small portion of the overall code. Once the performance sensitive code paths are rewritten, it matters less whether there is a small performance penalty for the remaining C++ code that is less sensitive to performance. But, at Google Scale, the cost of the developer-hours to maintain that fork would probably be less than the cost of the small increase in CPU hours that removing the fork would result in, so... yeah, maybe forever or until there is an upstream solution. Maintaining a patchset like this would still cost way less than maintaining an entire compiler and all the language tooling needed to support that language... does anyone really disagree? A new language is far more than just a compiler, let alone a patch for a compiler. > Would that be a good idea for anyone? IMHO, it definitely seems better than Carbon.