On 20 April 2015 at 18:07, Thomas Jordan wrote:

I had a similar idea for a new smart pointer that would aim to obsolete the

...

shared_ptr-to-const idiom. The problem I found with that idiom is that it only guarantees that you can't change it. There's no promise that somebody else doesn't have a non-const ref to the data and so it could in the worst case completely change from under your feet (even if you know it won't get destroyed).

ValueRef doesn't expose (shared) pointers/pointees, they are a hidden, implementation detail. Its interface just deals in values (as shown in the example usage).

Absolutely! Hence the ref in the name. :) I kept the pointer as part of the interface seeing as I saw it as a smart pointer to replace another smart pointer, but either direction is not wrong for sure. The thing I like about the schrodinger_ptr is that I can carry on mutating it while nobody else is looking, it seems with yours you would have to add all data to it on it's construction, is that right? So say it's collecting information from over a network, building up a schrodinger_ptr with a push_back every time it receives something from the network. Once the network sends the finished signal, the object that owns the schrodinger_ptr can spin up a bunch of threads (or whatever) to do some work on the data collected, each of them taking a shallow copy of the pointer. Now each thread has the guarantee that nobody will change that data because they know that as they own it it won't be unique to anybody else.