I wish all qualifiers were revisited with an eye for simplification

[Manu]

On Tue, Aug 4, 2020 at 6:26 PM Simen Kjærås via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On Tuesday, 4 August 2020 at 07:38:26 UTC, Sebastiaan Koppe wrote:
> > On Monday, 3 August 2020 at 21:56:34 UTC, Manu wrote:
> >> Shared recently received a `-preview` which makes it really
> >> mean something;
> >> this is what shared means:
> >> 1. The data is shared; therefore, it is invalid to read or
> >> write that
> >> memory.
> >> 2. The reason this is useful as an attribute, is because you
> >> are able to
> >> attribute methods. Ability to author a set of threadsafe
> >> methods and
> >> clearly distinguish them from non-threadsafe methods is a
> >> powerful
> >> advantage over C++.
> >
> > For some reason I often end up with multiple threads and the
> > coordination that comes with it. Shared has been very helpful
> > for me and I am using no. 2 with good success.
> >
> > There is just one thing about shared I don't understand. If I
> > design my object such that the non-shared methods are to be
> > used thread-local and the shared methods from any thread, it
> > follows that I should be able to call said shared methods from
> > both a shared and non-shared instance of that object.
> >
> > Often I workaround it be introducing a non shared method that
> > forwards to the shared method by means of casting.
>
> With DIP1024, any type should be implicitly castable to shared.
> This means you should always be able to call shared methods on
> any object. Far as I can see, this is not implemented.
>
> For a type with no thread-safe interface that means anyone with a
> shared reference to it can call absolutely no methods on it, and
> not read or write any of its fields. Kinda useless, but that's
> the point. If you want to manipulate it, you will need to cast
> away shared, which is non- at safe and a red flag.
>
> For a type with a thread-safe interface, there may be methods
> that can't be called, but some subset will be callable. These
> must be written such that they are thread-safe, and any
> non-shared methods must be written such that they do not break
> the thread-safety of shared methods (but non-shared methods may
> be non-thread-safe if called on multiple threads, since that
> should not happen).
>
> In other words, DIP1024 assumes you will have at most one
> non-shared reference to an object, and that no methods on an
> object are written in such a way that they break thread-safety
> under this assumption.
>
> --
>    Simen
>

I don't think what you describe has anything to do with DIP1024.
What you're describing is the scheme I was arguing for 1-2 years ago, but
Walter rejected it and presented DIP1024 instead.
DIP1024 was a step in the right direction, so I supported it at that time,
but it doesn't change any definitions about thread-safety of methods, and
it's not a complete solution. It just adds the restrictions that should
have been there from the start; that is, `shared` has no read or write
access to data.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20200804/1deb6982/attachment-0001.htm>