DIP 1024--Shared Atomics--Community Review Round 1

[Manu]

On Sat, Oct 12, 2019 at 3:35 PM Ola Fosheim Grøstad via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Saturday, 12 October 2019 at 21:28:36 UTC, Jonathan M Davis
> wrote:
> > The fact that we have thread-local in the language requires
> > that the type system then have the concept of shared. So, there
> > should be no question about that.
>
> Well, my understanding from what you wrote is that the shared
> marker is 100% syntactical and has no semantic implications.

The semantic implication is that there is no read or write access...
just the same as how const says there is no write access.

> In that case it can be done as a library meta programming construct
> (type wrapping).

We can't define type constructors in a library sadly. You could apply
the same argument to const.

And aside from that, it belongs in the language due to the simple fact
that it defines D's thread-local by default.
If you think about it, it's not really the definition of thread-local
by default that leads to shared... it's actually that shared existing
in the language defines thread-local by default.
If there was no shared, then there couldn't possibly be thread-local
by default, as D is specified. shared is fundamental to D, it's just
that it's semantics have been poorly understood because it's
historically had relatively little use.

> You just need a way to restrict application of
> the constructs  based on code structure (@safe). So one could
> establish a syntactical solution that is perfectly suitable for
> meta programming?
>
> But you could probably do better by introducing an effectsbased
> typesystem.
>
> Anyway, based on what you said shared does not have to be in the
> language and could be replaced by more expressive metaprogramming
> mechanisms. I think.

It's like I said above; shared MUST be in the language, because it
defines one of the fundamental language semantics; thread-local by
default.