Hacker News Reader

Comment by fooker | Hacker News Reader

>if the vector is marked as immutable

So, mark it as const here and see the same effect?

Not really the same thing. const will stop you from mutating the vector, but it won't stop you taking a reference to an element you get in a const vector.

So, if you have a const reference, you can't make this mistake in it's entirety, but you can certainly make the mistake of keeping a reference to something you got through a const pointer.

Also, marking as const is something you have to opt-in to, and there is still disagreement on the value of const.

That is a library design issue. You can certainly design a vector that is immutable by default and can only allow you to get references when immutable and push_back when mutable.

That is the point of C++, things other languages do at a language level you can easily design as a library without paying a cost if you do not use it.

What does cost mean here? Performance?

You do not pay a performance cost for borrowing semantics in rust.

This still doesn't solve the problem because there is nothing stopping you from having both immutable & non-immutable references to the same data structure. And does not enforce that there are no references hanging around when you go from immutable to mutable.

Which is precisely what Rust does.

Marking it as const will not allow you to push_back. c++ has no problem letting you maintain a reference to an element in the vector while calling push_back.

And rust will? push_back on an immutable object sounds rather strange.

Given a mutable vector:

c++ will let you push_back while holding a reference to an element of that vector. rust will not.

Reply on news.ycombinator.com