On 22.10.18 03:01, Manu wrote:
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?
(Also, yes, some people do that because std::map does not provide an
interface to augment the binary search tree.)
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.
Yes, exactly what I said.
Where did I ever say anything like that? I'm sure I've never said
this.
???
I said that you are proposing to allow implicit conversions to shared
for all classes, not only core.atomic.Atomic, and the last time you said
it was the previous sentence of the same post.
How do these transformations of what I've said keep happening?
...
You literally said that nobody changes core.atomic.Atomic. Anyway, even
if I bought that @safe somehow should not be checked within druntime (I
don't), bringing up this example does not make for a coherent argument
why implicit conversion to shared should be allowed for all classes.
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 are capable of doing so as soon as you provide them a @trusted
function that treats data as shared that they can access as unshared.
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.
Accessing private members of aggregates in the same module is @safe.
tupleof is @safe too.
