October 02, 2019
Also cast() doesn't strip qualifiers

shared int[] a;
pragma(msg,typeof(cast()a).stringof);

prints "shared(int)[]"
October 02, 2019
On 10/1/2019 11:30 PM, Manu wrote:
> I'm confused, which is it, A or B? I presume B, and my prior commentary applies.

A

October 02, 2019
On Wednesday, 2 October 2019 at 08:55:59 UTC, Kagamin wrote:
> Access to shared memory should be disallowed only for safe code, but not for system code.

That definition doesn't play nice with safety inference i.e. templates.

It should be that shared memory access is disabled in all contexts,
which must be worked around with casts,
which makes the function @system,
which must then be encapsulated with a @trusted interface in order to use in @safe code.
October 02, 2019
On Wednesday, 2 October 2019 at 08:55:59 UTC, Kagamin wrote:
> Access to shared memory should be disallowed only for safe code, but not for system code. For safe code it's justified, because safety is unavoidable there, for system code there's a concern of ease of use of shared data, which is affected by littering and is not addressed in this DIP. Stripping shared qualifier off for assignment isn't necessarily correct if, say, the data type switches between atomic and nonatomic reference counting based on its type.

@system code can always cast away shared.
October 02, 2019
On Wednesday, 2 October 2019 at 09:00:54 UTC, Kagamin wrote:
> Also cast() doesn't strip qualifiers
>
> shared int[] a;
> pragma(msg,typeof(cast()a).stringof);
>
> prints "shared(int)[]"

That's because `shared int[] a` is really `shared(int[] a)`, so cast() only strips the top level shared off.
October 02, 2019
On Wed, Oct 2, 2019 at 2:10 AM Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 10/1/2019 11:30 PM, Manu wrote:
> > I'm confused, which is it, A or B? I presume B, and my prior commentary applies.
>
> A

In that case, I don't understand the only code shown in the DIP; you show freely reading from and assigning to a shared int... that should be an error, and there should be atomicLoad/astomicStore in those locations?
October 02, 2019
On Wed, Oct 2, 2019 at 10:21 AM Manu <turkeyman@gmail.com> wrote:
>
> On Wed, Oct 2, 2019 at 2:10 AM Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >
> > On 10/1/2019 11:30 PM, Manu wrote:
> > > I'm confused, which is it, A or B? I presume B, and my prior commentary applies.
> >
> > A
>
> In that case, I don't understand the only code shown in the DIP; you show freely reading from and assigning to a shared int... that should be an error, and there should be atomicLoad/astomicStore in those locations?

Also the text: "Atomic reads perform an acquire operation, writes
perform a release
operation, and read-modify-write performs an acquire, then a
modification, and then a release."

What does that mean? I don't know what that's talking about. Please correct the DIP so we can understand it.
October 02, 2019
On Wednesday, 2 October 2019 at 17:21:59 UTC, Manu wrote:
> On Wed, Oct 2, 2019 at 2:10 AM Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>> On 10/1/2019 11:30 PM, Manu wrote:
>> > I'm confused, which is it, A or B? I presume B, and my prior commentary applies.
>>
>> A
>
> In that case, I don't understand the only code shown in the DIP; you show freely reading from and assigning to a shared int... that should be an error, and there should be atomicLoad/astomicStore in those locations?

My understanding is that the compiler rewrites that code to use core.atomic.
October 02, 2019
On Wednesday, 2 October 2019 at 17:51:09 UTC, Atila Neves wrote:
> On Wednesday, 2 October 2019 at 17:21:59 UTC, Manu wrote:
>> On Wed, Oct 2, 2019 at 2:10 AM Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>
>>> On 10/1/2019 11:30 PM, Manu wrote:
>>> > I'm confused, which is it, A or B? I presume B, and my prior commentary applies.
>>>
>>> A
>>
>> In that case, I don't understand the only code shown in the DIP; you show freely reading from and assigning to a shared int... that should be an error, and there should be atomicLoad/astomicStore in those locations?
>
> My understanding is that the compiler rewrites that code to use core.atomic.

Why can't it import core.atomic automatically then?

-Alex
October 02, 2019
On Wed, Oct 2, 2019 at 10:55 AM Atila Neves via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Wednesday, 2 October 2019 at 17:21:59 UTC, Manu wrote:
> > On Wed, Oct 2, 2019 at 2:10 AM Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >>
> >> On 10/1/2019 11:30 PM, Manu wrote:
> >> > I'm confused, which is it, A or B? I presume B, and my prior commentary applies.
> >>
> >> A
> >
> > In that case, I don't understand the only code shown in the DIP; you show freely reading from and assigning to a shared int... that should be an error, and there should be atomicLoad/astomicStore in those locations?
>
> My understanding is that the compiler rewrites that code to use core.atomic.

I asked Walter a couple posts up whether or not that's what he meant
(A/B), and he said A:
"""
By prohibiting direct access to shared data, the user will be required
to use core.atomic and to consider the correctness of their code.
This change will require using core.atomic or equivalent functions to
read and write to shared memory objects. It will prevent unintended,
inadvertent non-use of atomic access.
"""
...which is distinctly not that.