Last time we talked about shared, I think we all agreed on one thing; shared should hot have read/write access to data members.

Does anyone know how to implement this? I would really like to try some important experiments with shared if it worked.

On 2019-03-19 21:08, Manu wrote:
> Last time we talked about shared, I think we all agreed on one thing;
> shared should hot have read/write access to data members.

Not exactly sure of what you're looking for but write access is already disable [1].

> Does anyone know how to implement this? I would really like to try
> some important experiments with shared if it worked.

If it's only the read access that is left to disable I recommend looking at how the write access is disable and try to do the same for read. I suggest to do a project wide search for the error message for write operations, seems pretty unique. Then go from there.

[1] https://run.dlang.io/is/ZJ5maE

-- 
/Jacob Carlborg

On Tuesday, 19 March 2019 at 20:16:03 UTC, Jacob Carlborg wrote:
> On 2019-03-19 21:08, Manu wrote:
>> Last time we talked about shared, I think we all agreed on one thing;
>> shared should hot have read/write access to data members.
>
> Not exactly sure of what you're looking for but write access is already disable [1].
>
>> Does anyone know how to implement this? I would really like to try
>> some important experiments with shared if it worked.
>
> If it's only the read access that is left to disable I recommend looking at how the write access is disable and try to do the same for read. I suggest to do a project wide search for the error message for write operations, seems pretty unique. Then go from there.
>
> [1] https://run.dlang.io/is/ZJ5maE

Only read-write-modify are disabled, you can still write as long as you don't read from it at the same time.

shared int global;

shared class Foo
{
    int a;
}

void main()
{
    auto foo = new shared Foo;
    foo.a = 1;
}

On Tuesday, 19 March 2019 at 20:16:03 UTC, Jacob Carlborg wrote:
> On 2019-03-19 21:08, Manu wrote:
>> Last time we talked about shared, I think we all agreed on one thing;
>> shared should hot have read/write access to data members.
>
> Not exactly sure of what you're looking for but write access is already disable [1].
>
>> Does anyone know how to implement this? I would really like to try
>> some important experiments with shared if it worked.
>
> If it's only the read access that is left to disable I recommend looking at how the write access is disable and try to do the same for read. I suggest to do a project wide search for the error message for write operations, seems pretty unique. Then go from there.
>
> [1] https://run.dlang.io/is/ZJ5maE

A more obvious example of it being misused:

shared int global;

shared class Foo
{
    int a;
}

void main()
{
    auto foo = new shared Foo;
    foo.a = foo.a + 1;
}

On Tuesday, 19 March 2019 at 20:08:37 UTC, Manu wrote:
> Last time we talked about shared, I think we all agreed on one thing; shared should hot have read/write access to data members.
>
> Does anyone know how to implement this? I would really like to try some important experiments with shared if it worked.

This looks like a good place to start:
https://github.com/dlang/dmd/commit/7535f3dc86e9e88c4ee609dd98b5305224c3b88a

On Tuesday, 19 March 2019 at 20:08:37 UTC, Manu wrote:
> Last time we talked about shared, I think we all agreed on one thing; shared should hot have read/write access to data members.
>
> Does anyone know how to implement this? I would really like to try some important experiments with shared if it worked.

shared qualifier provides a guarantee that thread local data is thread local, it doesn't provide safety for concurrency, not supposed to, because it's not realistically feasible at such low level, and attempts to do it like yours only add noise, complicate reasoning and make errors only more likely. Normally it's unshared data that should have a qualifier, because that's actually a feature being provided, but because it would be a nuisance, the opposite was done.

On Tue, Mar 19, 2019 at 1:20 PM Jacob Carlborg via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 2019-03-19 21:08, Manu wrote:
> > Last time we talked about shared, I think we all agreed on one thing; shared should hot have read/write access to data members.
>
> Not exactly sure of what you're looking for but write access is already disable [1].
>
> > Does anyone know how to implement this? I would really like to try some important experiments with shared if it worked.
>
> If it's only the read access that is left to disable I recommend looking at how the write access is disable and try to do the same for read. I suggest to do a project wide search for the error message for write operations, seems pretty unique. Then go from there.
>
> [1] https://run.dlang.io/is/ZJ5maE
>
> --
> /Jacob Carlborg


Erm, change `++` to `= 10`.
Read/write from a shared thing should be a compile error in every circumstance.

On Tue, Mar 19, 2019 at 2:25 PM Kagamin via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Tuesday, 19 March 2019 at 20:08:37 UTC, Manu wrote:
> > Last time we talked about shared, I think we all agreed on one thing; shared should hot have read/write access to data members.
> >
> > Does anyone know how to implement this? I would really like to try some important experiments with shared if it worked.
>
> shared qualifier provides a guarantee that thread local data is thread local, it doesn't provide safety for concurrency, not supposed to, because it's not realistically feasible at such low level, and attempts to do it like yours only add noise, complicate reasoning and make errors only more likely. Normally it's unshared data that should have a qualifier, because that's actually a feature being provided, but because it would be a nuisance, the opposite was done.

I have literally no idea what you're talking about.

On Tuesday, 19 March 2019 at 21:20:58 UTC, Kagamin wrote:
> On Tuesday, 19 March 2019 at 20:08:37 UTC, Manu wrote:
>> Last time we talked about shared, I think we all agreed on one thing; shared should hot have read/write access to data members.
>>
>> Does anyone know how to implement this? I would really like to try some important experiments with shared if it worked.
>
> shared qualifier provides a guarantee that thread local data is thread local, it doesn't provide safety for concurrency, not supposed to, because it's not realistically feasible at such low level, and attempts to do it like yours only add noise, complicate reasoning and make errors only more likely. Normally it's unshared data that should have a qualifier, because that's actually a feature being provided, but because it would be a nuisance, the opposite was done.

In it's current form the `shared` qualifier is not improving the thread-safety
of D code. Manus proposal does improve thread-safety.
I am strongly in favor for considering it seriously.

Being conservative and disallowing all access is by far the most sensible handling
if safety is a concern.

On Wednesday, 20 March 2019 at 13:25:01 UTC, Stefan Koch wrote:
> In it's current form the `shared` qualifier is not improving the thread-safety
> of D code.

It does, proof: https://issues.dlang.org/show_bug.cgi?id=6585

> Being conservative and disallowing all access is by far the most sensible handling
> if safety is a concern.

Added noise and cognitive load on programmer causes more bugs, not more safety. shared is already restrictive enough to handle, making it more restrictive will only make people give up on it more often.