shared - i need it to be useful

[Manu]

On Sun, Oct 21, 2018 at 5:55 PM Timon Gehr via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On 22.10.18 02:45, Manu wrote:
> > On Sun, Oct 21, 2018 at 5:35 PM Timon Gehr via Digitalmars-d
> > <digitalmars-d at puremagic.com> wrote:
> >>
> >> On 21.10.18 20:46, Manu wrote:
> >>>> Shared data is only useful if, at some point, it is read/written, presumably by
> >>>> casting it to unshared in @trusted code. As soon as that is done, you've got a
> >>>> data race with the other existing unshared aliases.
> >>> If such a race is possible, then the @trusted function is not
> >>> threadsafe, so it is not @trusted by definition.
> >>> You wrote a bad @trusted function, and you should feel bad.
> >>> ...
> >>
> >> I wonder where this "each piece of code is maintained by only one person
> >> and furthermore this is the only person that will suffer if the code has
> >> bugs" mentality comes from. It is very popular as well as obviously
> >> nonsense.
> >>
> >>> The simplest way to guarantee that no unsafe access is possible is to
> >>> use encapsulation to assure no unregulated access exists.
> >>
> >> This only works if untrusted programmers (i.e. programmers who are only
> >> allowed to write/modify @safe code) are not allowed to change your
> >> class. I.e. it does not work.
> >
> > Have you ever cracked open std::map and 'fixed' it because you thought
> > it was bad?
> > Of course not. Same applies here. Nobody 'fixes' core.atomic.Atomic
> > without understanding what they're doing.
> >
>
> You are not proposing to let core.atomic.Atomic convert to shared
> implicitly, you are proposing to do that for all classes.

You can always implicitly convert to shared.
Where did I ever say anything like that? I'm sure I've never said
this. How do these transformations of what I've said keep happening?

> > You seem to be stuck on the detail whether you can trust the @trusted
> > author though...
>
> Again: the @safe author is the problem.

I don't follow. The @safe author is incapable of doing threadsafety
violation. They can only combine threadsafe functions.
They can certainly produce a program that doesn't work, and they are
capable of ordering issues, but that's not the same as data-race
related crash bugs.