Manu's `shared` vs the @trusted promise

[ag0aep6g]

On 22.10.18 11:33, Manu wrote:
> On Sun, Oct 21, 2018 at 3:05 PM ag0aep6g via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
[...]
> It's @trusted, not @safe... so I don't think you can say "It's invalid
> because we can even possibly write an Atomic.badboy" (I would agree to
> that statement if it were @safe).
> That's the thing about @trusted, you have to trust the engineer to
> confirm contextual correctness.

Your definition of @trusted is weaker than mine. I think the one I gave 
is the one that's in the spec and the one that Walter and Timon work with.

> But semantics aside, how and why did you add code to this module? Do
> you usually add code to druntime or phobos?
> Assuming you did add code to this module, are you telling me that you
> don't understand what Atomic() does, and you also did not understand
> the rules of `shared`? You can't be trusted to write threadsafe code
> if you don't understand `shared`s rules.
> My point is, do you genuinely believe this is a high-risk? When did
> you last rewrite Atomic(T) because you didn't like the one in
> druntime? Have you ever heard of a case of that?
> 
> I mean, I understand it's _possible_ to violate incr()'s promise, and
> that's why it's @trusted, and not @safe. But what's the probability of
> that happening by accident... and would you *honestly* make an
> argument that this unlikely scenario is more likely to occur than any
> of your 900 high-level engineers making any sort of mistake with
> respect to the *use* of shared's current rules, which require unsafe
> interaction at every call, by every end-user?
> Most users don't modify druntime.[...]
> I agree the situation you fear is technically possible, but I think
> it's very unlikely,

You're arguing with probability while the other camp is entrenched in 
fundamentals. The goal is a very strong @safe. All @safe code must be 
compiler-verifiable safe. With the weaker @trusted, that doesn't hold 
when the @safe code is next to @trusted code. So the weaker @trusted is 
unacceptable.

By the way, can you dial down the confrontational rhetoric, please? I'm 
pretty much trying to help get your point across here. I don't need 
snarky questions/remarks about my ability to write thread-safe code. 
Even if I can't write correct code, it's besides the point.

> and in balance to the risks associated with shared
> today, which is completely unsafe at the user-facing level, and also
> completely unregulated (you can access members freely)...

I think most agree it's bad that `shared` data can currently be accessed 
freely without casting, without atomics, without synchronization. I know 
that I agree.

[...]
> I've said on at least 5 other occasions, I'm sure there are a whole
> lot of options we can explore to assist and improve the probability
> that the ground-level author doesn't make a mistake (although I am
> quite confident you'd be wasting your time, because they won't make a
> mistake like this anyway).
> That conversation has nothing to do with the validity of the rules
> though, which is what the other 400 post thread is about.

The perception is that one has to break the (stronger) @trusted promise 
in order to do anything with your version of `shared`. And that's 
perceived as bad.

So you have to show that breaking the @trusted promise is not necessary. 
I've tried to show that. Or you have to show that a weaker @trusted is 
preferable to the stronger one. Convincing people of that would be a 
hard task, I think.

> If you *do* trust the 5-10 @trusted functions in the library; Is my
> scheme sound?

If you can implement them without breaking the (strong) @trusted 
promise, then I guess so. If you can't, then no (arguably, depending on 
how @trusted is defined).

[...]
> We can fuss about the details until the cows come home, but I'm
> finding it impossible to get everyone on the same page in the first
> place.

I think we're making progress right here. It seems to me that there are 
two slightly different definitions of @trusted floating around. Ideally, 
everyone would agree which one is correct (or more useful). Things might 
fall into place then.