shared - i need it to be useful

Manu turkeyman at gmail.com
Mon Oct 22 00:45:01 UTC 2018


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 seem to be stuck on the detail whether you can trust the @trusted
author though... that is a reasonable point of debate, but it's a
slightly separate topic. I am confident that the number of @trusted
functions required to found a useful stack are low, probably countable
with fingers, and always in a library.

If we can put aside that point of debate just for now; whether you
feel the @trusted author can be trusted, assuming that they can, does
the model work? Can you break the model as I have presented it?
If not; if the model is sound, then we can begin the discussion you're
alluding to and talk about opportunities to improve on static
guarantees for @trusted authors, or ways to communicate their
responsibility clearly, and patterns to assure success.


More information about the Digitalmars-d mailing list