Very limited shared promotion

[Jonathan M Davis]

On Saturday, June 22, 2019 1:57:22 AM MDT Walter Bright via Digitalmars-d 
wrote:
> On 6/21/2019 5:33 PM, Manu wrote:
> > Because it's safe to do from the calling scope's perspective,
>
> No, it is not.
>
> > Compiler is not required to check the users work in @trusted code. It
> > assumes the user conformed with language requirements.
>
> The language does not require you to put the fence in, hence it cannot
> assume you did.
>
> I don't know how else to explain it to you. Your example does not work.

If I understand correctly, Manu and Timon are arguing that because you're
dealing with scope with only thread-local variables, the compiler knows that
the state of the thread-local variable is properly up-to-date, because in
@safe code, it's impossible for it to be otherwise. And then if your
@trusted code ensures that the data on the original thread is up-to-date
after it does its thing with using the object on other threads, then it all
works. And as such, they think that it should be fine for the compiler to
implicitly convert to shared with scope, because it's up to the programmer
to make sure that all of the normal guarantees are in place and none of the
guarantees are violated without @trusted being involved.

This makes sense to me as long as the programmer is doing the casting,
because then @safe still isn't doing anything with shared. It's just the
programmer doing what @trusted needs to do and making sure that the normal
guarantees are maintained. The problem is that if the compiler then
implicitly converts to scope shared in @safe code, then all of a sudden,
@safe needs to worry about whether the variable is properly up-to-date,
since it's no longer just assuming it based on it being thread-local. At
best, it's assuming that the scope shared variable will never actually be
shared across threads, since without @trusted, it wouldn't be possible to
share it across threads. And if it's assuming that, then why on earth would
it implicitly convert the variable to shared?

This whole idea seems to rest on the premise that the compiler will do a
conversion for you, because it can't be a problem in @safe code without
@trusted being involved, but it's also completely useless without @trusted
being involved, and the compiler doesn't make assumptions based on @trusted.
It makes them based on @safe. @trusted is just the way for the programmer to
provide something that the compiler treats as @safe even though it's the
programmer making sure that it is instead of the compiler being able to
actually verify it. It's not going to treat an @trusted function any
differently from an @safe one aside from the mangling of the function name,
and arguably, @safe and @trusted should have had the same name mangling in
the first place, since there is no difference from the standpoint of the
caller. The difference is only in how the implementation is checked by the
compiler.

As long as @safe code doesn't actually benefit from the implicit conversion
to scope shared, it makes no sense to me to have it happen. The entire point
is for it to be used with @trusted stuff. And if that's the case, then why
not just have the cast be explicit and @trusted like it normally would be?

- Jonathan M Davis