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

Manu turkeyman at gmail.com
Wed Oct 9 18:25:36 UTC 2019

On Mon, Oct 7, 2019 at 1:05 AM Kagamin via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Friday, 4 October 2019 at 12:22:16 UTC, Stefan Koch wrote:
> > The reason why you want shared access to be forbidden by
> > default is to see where synchronization is required and force
> > you to think about it.
> > In all your code not just safe code.
> That's achieved by writing safe code, so the failure requires
> transition to trusted code, where there's type system and lack of
> conversion between shared and unshared data. Adding churn
> indefinitely isn't very practical, it increases cognitive load on
> programmer and diverts resources that can be spent on thinking
> about synchronization. Also the idea ignores the problem that
> people deem it difficult to work with shared data, adding more
> churn only worsens that problem, which is traded for an alleged
> solution to a hypothetical problem.

This made exactly no sense to me. I don't know what you're saying here.
That said, based on your past posts, I think I need to assure you that
it is **NEVER** acceptable to freely read/write to shared data, and
that doesn't only apply to @safe code.

I wish Walter would update this DIP, but based on his comments, I
think it's going the right way...?

More information about the Digitalmars-d mailing list