Manu's `shared` vs the @trusted promise

[ag0aep6g]

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.