On 22.10.18 10:39, Simen Kjærås wrote:
On Sunday, 21 October 2018 at 22:03:00 UTC, ag0aep6g wrote:
[...]
It's invalid only if Atomic.badboy exists.
I don't agree. I prefer the stronger @trusted. As far as I know, the
stronger one is the current one.
Essentially, since the module is the unit of encapsulation, it also
needs to be the unit of programmer responsibility.
[...]
----
struct Atomic
{
shared/*!*/ int x;
void incr() shared @trusted { /* ... */ }
/* Now this gets rejected by the compiler: */
void badboy() @safe { ++x; } /* compiler error */
}
----
With a `shared int x` there's no way that @safe code might access it,
so the @trusted promise is kept.
It's clearly better to mark x as shared, yes. However, I fail to see how
this is significantly different from the above - J. Random Newbie can
still open that file, remove the 'shared' qualifier on x, and rewrite
badboy to be thread-unsafe. If we're going to assume that bad actors
have write-access to all files, there's no end to the trouble that can
be had.
It's not about bad actors, it's about mistakes and finding them. Of
course, you can still makes mistakes with the stronger @trusted, but
they will be in @trusted code.
In the example, if anything's wrong you know that the mistake must be in
`incr`, because it's the only @trusted function. You don't even have to
look at the @safe code. The compiler can check that it's ok.
