On Sun, Oct 21, 2018 at 5:55 PM Timon Gehr via Digitalmars-d <digitalmars-d@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@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.