shared - i need it to be useful

[Manu]

On Mon, Oct 15, 2018 at 7:15 PM Isaac S. via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Tuesday, 16 October 2018 at 00:36:12 UTC, Manu wrote:
> > *snip*
> >
> > Yes, except maybe I didn't make it clear that I DO expect the
> > un-shared methods to be aware that a sibling shared method does
> > exist
> > (you wrote it!), and that it may manipulate some state, so *if*
> > the
> > un-shared method does interact with the same data that the
> > shared
> > method may manipulate (in many cases, it won't; it's likely
> > only a
> > small subset of an object's functionality that may have
> > thread-safe
> > access), then the un-shared method does need to acknowledge that
> > functional overlap.
> > So even though a method is un-shared, it still needs to be
> > aware that
> > it may have sibling methods that are shared. If they don't
> > access an
> > overlapping data-set, no special handling is required. If they
> > do
> > overlap, they may need to coordinate appropriately.
>
> 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 ;)

> It's also easy to acknowledge that implicit conversion to shared
> has its uses.

I actually know of many real uses for this case.

> Instead of forcing one way or another, how about we leave the
> decision up to the programmer? Say something like "alias this
> shared;" enables implicit conversion to shared.

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.