shared - i need it to be useful

[Manu]

On Mon, Oct 15, 2018 at 8:55 PM Isaac S. via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Tuesday, 16 October 2018 at 02:26:04 UTC, Manu wrote:
> >> I understand your point but I think the current shared (no
> >> implicit conversion) has its uses. It can be quite useful to
> >> have one interface for when an object is shared and one for
> >> when it is not (one with and without the synchronization
> >> cost). Sure, something as trivial as a counter can be
> >> re-implemented in both ways but more complex objects would
> >> easily result in extreme code duplication.
> >
> > If you can give a single 'use', I'm all ears ;)
>
> My usages are a custom ref counted template and list types (which
> are built on top of the former). The ref counted template will
> initialize naively when not shared but utilize compare-and-set
> and thread yielding if needed when shared (ensureInitialized can
> occur any time after declaration). The list types (which are not
> shared-compatible *yet*) will utilize a read-write mutex only
> when shared (no cost beyond a little unused memory to non-shared
> objects). As such, casting any of the non-shared versions of
> these types to shared would be unsafe.
>
> (Technically the types can be safely casted to shared so long as
> no non-shared
> reference to them exists and vice versa.)

Can you link to code? It doesn't sound incompatible with my proposal.
Mutexes are blunt instruments, and easy to model. My whole suggestion
has virtually no effect on the mutex protected case, which is what
most people seem to talk about.

> > That might be fine.
> > Like I said in OP, the first point that I think needs to be
> > agreed on,
> > is that shared can not read or write members. I think that's a
> > pre-requisite for any interesting development.
>
> I will agree that *outsiders* should not be able to read/write
> members of a shared object. I'm not sure whether your design
> means even within a shared function such members cannot be read
> from or written to.

Absolutely. Shared references can not access members, that's the rule.
It's completely unsafe to read or write to members of a shared thing. Period.
Attributing a method shared doesn't change that fact.

You can create a thread-local (ie, accessible) object from a shared
object by acquiring a lock on it for some duration, and it would be
helpful if the mechanism that fetches the lock also cast away shared
as part of the lock operation.

> If it does, the casting required may get a
> little annoying but isn't unworkable (especially since an
> unshared template can do the cast in an @trusted manner).

I agree users shouldn't write casts explicitly, they should use a lock
helper or something that grabs the lock and returns the un-shared
reference.
The existing behaviour is totally unacceptable though; shared objects
can read/write arbitrarily... what's the point of that? It gives the
impression that it's okay, but it's completely broken.
There is no situation where a shared thing can arbitrarily access its members.