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 seem to be stuck on the detail whether you can trust the @trusted
author though...
Again: the @safe author is the problem.
