C++ doesn't have a smart ponter for 'i will not need this for longer than something else' - shared pointer gets the overhead of reference counting. Rust makes borrows easy - taking and returning a unique_ptr is conceptually the same thing but the syntax makes it tedious. Borrows don't cover the case of I'll store it but whole program analisys would show I won't store it as long as the owner (i'm not a rust expert but I think my understanding is right here)

both languages don't have a good way to handle circular references should you need them (again my rust isn't strong but I think that is right). You are correct to say avoid that - but sometimes you need them.

▲

mgaunard 2 days ago | parent [-]

It does, it's called a pointer. You're literally not allowed to dereference a pointer once the pointee has ceased to exist, so by using them you're making the promise you'll ensure this is satisfied.

C++ is not limited to unique_ptr, the language (unlike Rust) allows you to define your own semantics of what a value is. You can then work in terms of copying or moving values, which makes lifetime management trivial as they are scope-bound.

▲

bluGill 2 days ago | parent [-]

Smart is the key. You can use a raw pointer, but that doesn't tell or enforce anything about lifetime. How long will that pointer be valid - can I save it to a class member - we don't know.

C++ gives you more more things, but none of them are enforced. (I'm sure Rust wants those same things at time - but since I'm not aware of anyone with any ideas how to enforce them so Rust has decided to not allow those - a reasonable choice overall, but sometimes annoying when it means you can't do something that you "know" is correct just because it can't be proved correct in the language)

▲

mgaunard 2 days ago | parent [-]

It remains a requirement, whether it is enforced or not.

Valid programs don't need guardrails, since you need to satisfy those requirements for the program to be valid in the first place.

	▲	bluGill 2 days ago \| parent [-]
		Humans have a bad history of getting things right without the guardrails. We know how to do it, but there often is one code path we didn't think about correctly - we may get it right 99.99% of the time, but that leaves a lot of mistakes in the code. I want guard rails to ensure that I got everything right, not just 99.99% of the cases right.