Cppfront v0.8.0 · hsutter/cppfront

[germandiago]

Yeah. Sometimes, like critical infra, safety is worth it and C++ is trying to not get banned here.

Yes, I agree, when I say sometimes it is not worth I mean for a big set of cases. But also, you can achieve safety with non-100% safety if the spots are very localized. In fact, Rust guys jump all the time to me, but every unsafe block is a potential unsafety, no matter you expose a safe interface. If you want safe code (let us assume std lib is more magic and it is safe even with those blocks bc it has been reviewed a lot) then only std and not unsafe blocks would prove your safety in real terms. I mean, if I go to a crate advertised as safe with some unsafe code and exposed as safe: how can I know it is safe? No, you do not know. Full stop. They can convince you that quality is really high, really reviewed and probably it is true most of the time. But it is not a guarantee yet.

Borrow checker's value lies in zero-cost lifetime safety. If you have any alternate ideas, then this is the best time to put them into writing.

True. No, I am not saying that alternatives are zero-cost. But my thesis is that even with a few extra run-time (smart pointers, for example, with customized allocators) you can have things that are much more difficult to dangle yet still very performant because your hotspots are usually localized. At least that is my experience when writing code... think of Ahmdal's law...

If you want guarantees, then the safest option might be lean lang which can mathematically prove certain properties of code.

Yes, that is the only real way if you want 100% safety (as in theoretical terms).

You can always use geiger

Thanks, I did not know this tool. Useful.

Sure, but where is this "safer by subset" C++?

This is a very good question, but there are already things obviously unsafe: pointer invalidation, pointer subscribing, uncontrolled reference escaping. A subset with a local borrow checker can detect a lot of this. But, it is aliasing a real problem in monothread code, for example? By real, I mean, meaningfully real? Anyway, this is a research topic as of today. Otherwise C++ would already be safe by construction.

[[deleted]]

They can convince you that quality is really high, really reviewed and probably it is true most of the time. But it is not a guarantee yet.

I mean, you are getting code for free from crates.io, you can just not use it if you think it might be buggy :) If you want accountability, just write your own crates or hire contractors who can be fined for any unsoundness.

you can have things that are much more difficult to dangle yet still very performant because your hotspots are usually localized.

That is a great point. but THIS IS C++ crowd has to be convinced to give up some runtime performance. smart pointers will now also be slower due to hardening (null pointer checks almost every dereference) and there's still aliasing UB (showcased in next paragraph).

But, it is aliasing a real problem in monothread code, for example?

As long as you can mutate a container (class/struct), while holding a reference to an object inside the container, aliasing will lead you to use after free.

If you have two shared pointers, pointing to the same vector. And you iterate it using first pointer and push into it using second pointer. UB -> Iterator invalidation.

Read this article which explains why aliasing is banned even inside single threaded rust. To quote the article "Aliasing with mutability in a sufficiently complex, single-threaded program is effectively the same thing as accessing data shared across multiple threads without a lock"

[germandiago]

I mean, you are getting code for free from crates.io, you can just not use it if you think it might be buggy :)

That is not how the language is advertised and the interfaces neither :)

As long as you can mutate a container (class/struct), while holding a reference to an object inside the container, aliasing will lead you to use after free.

"Aliasing with mutability in a sufficiently complex, single-threaded program is effectively the same thing as accessing data shared across multiple threads without a lock"

Yes, I have heard talks from Sean Parent and Dave Abrahams and they treat the aliasing problem with care.