On T= hu, Aug 25, 2016 at 3:10 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

On Thursday, August 25, 20= 16 at 3:29:28 AM UTC-4, Edward Catmur wrote:

On 25 Aug 2016 1:54 a.m., "Nicol Bolas" <jmck...@gmail.com> wrote:
>
> 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=A0wro= te:
>> > On Wednesday, August 24, 2016 at 3:39:33 AM UTC-4, Alexey Mam= ontov wrote:
>> >
>> > There is an interesting concept of pointers pair: const_share= d=C2=A0with mutable_unique.=C2=A0
>> >
>> > Const shared is move-constructible from mutable_unique: this = enqures that the value we have a const shared=C2=A0pointer to can not be re= ferences for edit from any other location (the problem=C2=A0that shared_ptr= <const T> can't solve).
>> >
>> > Why does it not solve this problem? Outside of `const_pointer= _cast` or similar gymnastics, if you have a `shared_ptr<const T>`, yo= u cannot 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 wa= y 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 similar? If you do `make_shared<const T&g= 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`.

If you do make_shared<T>(...) then you can get a share= d_ptr<T const> later that has the same target as the original shared_= ptr<T>.

I fail to see your point.

My = point is that `shared_ptr` gives a user all the tools that `const_shared_pt= r` gives the user for making a non-modifiable shared pointer to T. Namely, = `shared_ptr<const T>`. If you create it `const` initially, then nobod= y can take that away without an explicit `const_cast` or similar construct.=

This, in regards to the const-ness of `T`, `shared_ptr` is just as = guaranteed as the proposed `const_shared_ptr`. Indeed, you could do this:
template<typename T> using= const_shared_ptr =3D std<= span style=3D"color:rgb(102,102,0)">::shared_ptr<std::= add_const_t<T>>; template<typename T, template ...Args> auto make_const_s= hared(Args &&...args) { return std::make_share= d<std::add_const_t<T>>(std::forward<Args>(args)...); }
And you get the same `const` protection as the proposed `const_share= d_ptr`, so long as that is how you create them initially.

Right, but only if you control all the locat= ions where the shared_ptr<T [const]> is created and will be created i= n the future. If someone hands you a shared_ptr<T const> it might hav= e been created by make_shared<T const> but it might also have been cr= eated initially as a make_shared<T>, so you can't be sure that no= -one has a mutable handle to the object you're accessing.
>&g= t; > 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 al= low the implementation to be more efficient (ala `make_shared`). That is, y= ou construct the mutable unique value type, then move the value into your &= quot;const" COW shared object.
>> >
>> > So what you really have is `unique_value<T>` and `share= d_value<const T>`, with conversions between them. This also permits y= ou to have a mutable `shared_value<T>` if a user wants it, rather tha= n enforcing immutability at the interface level.
>>
>> Would that allow enforcement of non modification by an aliasing va= lue? There's two sides to immutability; there's "I can't m= odify it" and there's "no-one can modify it".
>
>
> Conceptually, it's a value type, so it wouldn't have aliasing = 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.

Sorry, I didn't mean aliasing in the sense of creating a= shared_ptr to a subobject, rather in the general sense of one pointer havi= ng the same target as another pointer, or one reference having the same ref= erent as another reference.

In your shared_value scheme, a modification to one shared_va= lue<T> can be observed by another shared_value with the same target. = Can you prevent a shared_value<T const> having the same target as a s= hared_value<T>?

The same way as I showed= for `shared_ptr`: make it `const` when you create the first one.

If= you want pure COW semantics from the type I've suggested, then you mak= e a `shared_value<const T>` at the point of origin. At no time do you= make a `shared_value<T>`.

But then you can *never* modify it; you can only copy it to a new mut= able value. Which is great for functional purity, but could also be ineffic= ient.

The thing = is, I've always thought we should have a `value_ptr<T>` type. Tha= t is, a type that *certainly* allocates memory for `T`, moves via moving th= e pointer, but copies itself by copying the object by value. This would be = useful for cases where `T` is expensive to move and/or throws on moving.
A `shared_value_ptr<T>` would not be an unreasonable pairing for= such a type. And then we could have `shared_value_ptr<const T>` serv= e the needs the OP requires for COW gymnastics, so long as there is a conve= rsion from `shared_value_ptr` to `value_ptr` which is permitted to avoid a = copy if the `shared_value_ptr` moved into it is the last one.

But that conversion would give you a value_p= tr<T const>, so it would still be immutable even when it should be sa= fe to mutate.

=C2=A0

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObcZYq%= 2BNrDQHD4QN2V_qZV%2BqBzPcMeh3725g8eF6_JD6g%40mail.gmail.com.
--94eb2c08a748ea6743053ae7090f-- .