On Wednesday, August 24, 2016 at 7:57:33 PM UTC-4, Edward = Catmur wrote:

On Wednesday, 24 = August 2016 15:45:12 UTC+1, Nicol Bolas =C2=A0wrote:
> On Wednesday, August 24, 2016 at 3:39:33 AM UTC-4, Alexey Mamontov= wrote:
>=20
> There is an interesting concept of pointers pair: const_shared=C2= =A0with mutable_unique.=C2=A0
>=20
> Const shared is move-constructible from mutable_unique: this enqur= es that the value we have a const shared=C2=A0pointer to can not be referen= ces for edit from any other location (the problem=C2=A0that shared_ptr<c= onst T> can't solve).
>=20
> Why does it not solve this problem? Outside of `const_pointer_cast= ` or similar gymnastics, if you have a `shared_ptr<const T>`, you can= not convert it into a `shared_ptr<T>`. Oh sure, you can always `get` = the pointer and `const_cast` it. But your `const_shared_ptr` has no way to = prevent that either.

But there can be an already existing shared_ptr<T> aliasing your = shared_ptr<T const>.

Without a `const_cast` or s= imilar? If you do `make_shared<const T>(...)`, I have no idea how you= would get the aliasing to `shared_ptr<T>` without a `const_cast` or = similar.

At least, not unless it's a pointer to a different `T`.
=C2=A0

The pro= posal here is that const_shared_ptr<T> can only be aliased by other c= onst_shared_ptr<T>s.

> > mutable_unique is also move constructible from the const shar= ed, while the following logic is perfomed: if the source is the last refere= nce, then the same pointer is moved to the mutable instance, otherwise it c= reates a copy using copy-constructor. This allowes to modify local instance= s while paying the lowest possible price, and making copies only if there a= re some other users of the same instance exist.
>=20
> I'm not sure I understand the conceptual foundation of what yo= u're asking for. I understand what all the pieces do; I just don't = understand the problem you're solving. In particular, why would constru= cting a `mutable_unique` from a `const_shared_ptr` invoke copy construction= ? If you're copying the value, then you're not accessing it by refe= rence. So is it a value type or a reference type?

In order to ensure that a const pointer cannot have its pointee concurr= ently modified by a mutable pointer.

Except that i= t can. The OP made it clear that if you take the last `const_shared_ptr` an= d turn it into a `mutable_unique`, then the `mutable_unique` doesn't= copy the value; it merely takes ownership of the pointer from the `con= st_shared_ptr`. So yes, it is possible to modify the supposedly const objec= t.

Just not directly through `const_shared_ptr`.

Structurally= , this all seems very much like a generalized COW, with the optimization th= at the last reference to the shared object doesn't need to copy when it= tries to write to it.
=C2=A0

> Or is this some form of copy-on-write value semantics, generalized to = all types? If that's the idea behind this, then the names of these type= s are completely wrong. They're not smart pointers; they're values.= And the fact that the const value is being "shared" is an implem= entation detail.

Well, other than the clone operation being an observable side effect.= =20

> Indeed, I would even go so far as to say that, if this is the idea= , then giving it an existing object to govern is really the wrong interface= .. Such a type should create the objects it manages internally; this would a= llow the implementation to be more efficient (ala `make_shared`). That is, = you construct the mutable unique value type, then move the value into your = "const" COW shared object.
>=20
> So what you really have is `unique_value<T>` and `shared_val= ue<const T>`, with conversions between them. This also permits you to= have a mutable `shared_value<T>` if a user wants it, rather than enf= orcing immutability at the interface level.

Would that allow enforcement of non modification by an aliasing value? = There's two sides to immutability; there's "I can't modify= it" and there's "no-one can modify it".

Conceptually, it's a value type, so it wouldn't have alia= sing of any form. What would that even mean? Would you be aliasing a value = with another value? Indeed, the OP excluded aliasing from `const_shared_ptr= `'s interface, since it doesn't make sense.

After all, if yo= ur `const_shared_ptr<T>` actually owns some object of type `U`, what = would it mean to make a `mutable_unique` copy? Are you asking to make a cop= y of the aliased pointer or the owned object? The latter is a bit problemat= ic, since it has been type-erased by that point.

> Of course, that also raises the question of a `weak_ptr` equivalent. D= oes this type need such a thing? With COW strings, the question was moot; s= trings are dumb arrays, so there was never any question of whether a COW st= ring could have a circular reference to itself. But with generalized COW ob= jects, that possibility now exists.

Would such a weak_value<T const> be invalidated if all the shared= _value<T const>s are converted to mutable?

They = would have to be, since there are no shared values out there for it to refe= rence.