On Sun, Oct 21, 2018 at 12:00 PM Timon Gehr via Digitalmars-d <[email protected]> wrote: > > On 21.10.18 17:54, Nicholas Wilson wrote: > > > >> As soon as that is done, you've got a data race with the other > >> existing unshared aliases. > > > > You're in @trusted code, that is the whole point. The onus is on the > > programmer to make that correct, same with regular @safe/@trusted@system > > code. > > Not all of the parties that participate in the data race are in @trusted > code. The point of @trusted is modularity: you manually check @trusted > code according to some set of restrictions and then you are sure that > there is no memory corruption. > > Note that you are not allowed to look at any of the @safe code while > checking your @trusted code. You will only see an opaque interface to > the @safe code that you call and all you know is that all the @safe code > type checks according to @safe rules. Note that there might be an > arbitrary number of @safe functions and methods that you do not see. > > Think about it this way: you first write all the @trusted and @system > code, and some evil guy who does not like you comes in after you looks > at your code and writes all the @safe code. If there is any memory > corruption, it will be your fault and you will face harsh consequences. > Now, design the @safe type checking rules. It won't be MP! > > Note that there may well be a good way to get the good properties of MP > without breaking the type system, but MP itself is not good because it > breaks @safe.
Show me. Nobody has been able to show that yet. I'd really like to know this.
