<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun., 23 Jun. 2019, 6:32 am Jonathan M Davis via Digitalmars-d, <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Saturday, June 22, 2019 1:57:22 AM MDT Walter Bright via Digitalmars-d <br>
wrote:<br>
> On 6/21/2019 5:33 PM, Manu wrote:<br>
> > Because it's safe to do from the calling scope's perspective,<br>
><br>
> No, it is not.<br>
><br>
> > Compiler is not required to check the users work in @trusted code. It<br>
> > assumes the user conformed with language requirements.<br>
><br>
> The language does not require you to put the fence in, hence it cannot<br>
> assume you did.<br>
><br>
> I don't know how else to explain it to you. Your example does not work.<br>
<br>
If I understand correctly, Manu and Timon are arguing that because you're<br>
dealing with scope with only thread-local variables, the compiler knows that<br>
the state of the thread-local variable is properly up-to-date, because in<br>
@safe code, it's impossible for it to be otherwise. And then if your<br>
@trusted code ensures that the data on the original thread is up-to-date<br>
after it does its thing with using the object on other threads, then it all<br>
works. And as such, they think that it should be fine for the compiler to<br>
implicitly convert to shared with scope, because it's up to the programmer<br>
to make sure that all of the normal guarantees are in place and none of the<br>
guarantees are violated without @trusted being involved.<br>
<br>
This makes sense to me as long as the programmer is doing the casting,<br>
because then @safe still isn't doing anything with shared. It's just the<br>
programmer doing what @trusted needs to do and making sure that the normal<br>
guarantees are maintained. The problem is that if the compiler then<br>
implicitly converts to scope shared in @safe code, then all of a sudden,<br>
@safe needs to worry about whether the variable is properly up-to-date,<br>
since it's no longer just assuming it based on it being thread-local. At<br>
best, it's assuming that the scope shared variable will never actually be<br>
shared across threads, since without @trusted, it wouldn't be possible to<br>
share it across threads. And if it's assuming that, then why on earth would<br>
it implicitly convert the variable to shared?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">You say this as someone who has obviously never or rarely tried to use shared (as I suspect basically everyone here is among, possibly including Walter).</div><div dir="auto"><br></div><div dir="auto">It's quite annoying to implement many identical shared and unshared method overloads. Most shared methods are threadsafe, and equally valid to call on thread-local data too.</div><div dir="auto">The hypothetical on trial is about @trusted code, but there are many useful cases where no @trusted code need be present for the mechanic to be useful and save a lot of noise.</div><div dir="auto"><br></div><div dir="auto">void atomicInc(ref scope shared(int) x);</div><div dir="auto"><br></div><div dir="auto">int x;</div><div dir="auto">atomicInc(x); // <-- perfectly safe</div><div dir="auto"><br></div><div dir="auto">That's a boring example, but I shouldn't need to write a second copy of the function when it is threadsafe.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This whole idea seems to rest on the premise that the compiler will do a<br>
conversion for you, because it can't be a problem in @safe code without<br>
@trusted being involved, but it's also completely useless without @trusted<br>
being involved,</blockquote></div></div><div dir="auto"><br></div><div dir="auto">Wrong. I wish people that have never tried to use shared would just let those of us that have, and want to make the language feature useful have some authority on the matter.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> and the compiler doesn't make assumptions based on @trusted.<br>
It makes them based on @safe. @trusted is just the way for the programmer to<br>
provide something that the compiler treats as @safe even though it's the<br>
programmer making sure that it is instead of the compiler being able to<br>
actually verify it.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">And in this case, the compiler may treat the scope ref as if it remained thread local and freely ignore the possibility of synchronisation issues, because that's the reality made possible by @safe. Any @trusted code must maintain those assumptions.</div><div dir="auto"></div><div dir="auto"><br></div><div dir="auto">It's<br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> not going to treat an @trusted function any<br>
differently from an @safe one aside from the mangling of the function name,<br>
and arguably, @safe and @trusted should have had the same name mangling in<br>
the first place, since there is no difference from the standpoint of the<br>
caller. The difference is only in how the implementation is checked by the<br>
compiler.<br>
<br>
As long as @safe code doesn't actually benefit from the implicit conversion<br>
to scope shared,</blockquote></div></div><div dir="auto"><br></div><div dir="auto">It does, because DRY and mitigating redundancy.</div><div dir="auto"></div><div dir="auto"><br></div><div dir="auto">it</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> makes no sense to me to have it happen. The entire point<br>
is for it to be used with @trusted stuff. </blockquote></div></div><div dir="auto"><br></div><div dir="auto">No, that's just this one example on trial. We had a huge weeks-long discussion 6 months ago about how the promotion is useful without @trusted code.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">And if that's the case, then why<br>
not just have the cast be explicit and @trusted like it normally would be?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Because you've overlooked the 99% case.</div></div>