On 22.10.18 11:33, Manu wrote:
On Sun, Oct 21, 2018 at 3:05 PM ag0aep6g via Digitalmars-d <digitalmars-d@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.
