> IIRC the Chromium devs (...)

Chromium is hardly a compiler or tooling project. Even if their devs aren't hacks, appeals to authority based on their perceived expertise hardly make any sense.

Having said that, there is no better litmus test than showing something working. If Dr Stroudtrup strongly believes in C++'s ability to provide Rust-like memory safety guarantees, there's no better person than him to prove him right (or wrong). If he does not have a proof of concept in the works, he's not in a good position to substantiate his claim.

FWIW, Chromium contains a Javascript compiler and developer tooling.

I'm not saying it's proof or anything. It is evidence that it's likely to be very hard (if not impossible).

> It is evidence that it's likely to be very hard

I don't agree. Chromium is an end-user of compilers and tooling that originated in forking a third-party desktop app. Developing C++ compilers and static code analyzers is way way outside of their wheelhouse. What they can and cannot do outside of their wheelhouse is hardly relevant or representative.

I think you under estimate just what level expertise and pull modern web engine requires. Google funded a ton of the work to support clang building code for Windows explicitly so they could standardize on clang for Chromium on all platforms. In turn they used the fact that they use a single toolchain across all platforms to add support for things like control flow integrity, which involved low level ABI and runtime changes to to the compiler and libc++. That requires tight cooperation between the Chromium and the compiler teams, and is definitely beyond a typical "end-user of compilers and tooling."

Admittedly my claims about Chromium are based on my observations as an outsider, but as someone who works on tooling (linkers) at a different large company that also has a web engine written in C++ I can tell you it is consistent with what I have seen up close... web engines (and particular JavaScript JITs) tend to push C++ tooling hard and often inspire major investment by the teams working on C++ specifically to support them.

In fact, over the years I have seen a number of people (including C++ committee members) who transitioned back and forth between the C++ compiler teams and the JavaScript JIT teams because they sometimes work very closely together, so in my experience the level C++ expertise on lot of the teams developing web engines tends to exceed anything but the actual C++ tooling teams supporting them, and developing C++ tooling is most certainly in their wheelhouse.

It can probably be done if you restrict some of the language features. e.g. reinterpret_cast, unprovable static_casts uninitialized pointers, etc etc.

Statically provable memory safety is probably possible in some sorts of code, like business process logic where performance isn't critical, and you can use std:: containers and copy everything.

A browser is a much more demanding environment, involving code generation, multithreading, caching, and low-overhead interfaces to complex data structures. Memory safety is extremely hard in that case.

So both could be true.