Thread-safe attribution

[Manu]

On Sat, Oct 6, 2018 at 7:40 PM Nicholas Wilson via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> [...]
>
> One thing that occurred to me is that _objects_ are shared,
> whereas _functions/methods_ (and their parameters) are thread
> safe .
>
> Theadsafe is kind of like a const (as to mutable/immutable) to
> threading, a promise to behave correctly in the presence of
> threading. thread safe references therefore must not escape.

Right, that's kinda what I want to model... but the more I think of
it, the more I think that experience can fit into `shared`, because
it's almost there, and the current incarnation of shared is
objectively useless.

Consider shared as is today;
struct Bob
{
  int x;
  void f() shared
  {
    x = 10; // <- this compiles... WAT?!
  }
}

Right now, if you have a shared instance, you can read/write to the
members... and that makes *absolutely no sense* no matter how you look
at it.
There is no reality where you have a shared thing, and accessing
members un-controlled can be safe.

Conventional wisdom is that when you have a shared thing, and you want
to do stuff with it, you must acquire locks (or whatever) and case
shared away. That should apply to f() above.

struct Bob
{
  int x;
  void f() shared
  {
    auto lock = getLock();
    auto unshared = shared_cast(&this);
    unshared.x = 10; // <- this is now okay.
  }
}

If we made a change were `shared` lost the ability to access
non-`shared` members, I don't think that would interfere with current
or proposed uses of shared in any way whatsoever... and we would make
shared useful in the process.