Very limited shared promotion

[Manu]

On Sun., 23 Jun. 2019, 6:32 am Jonathan M Davis via Digitalmars-d, <
digitalmars-d at puremagic.com> wrote:

> 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?
>

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).

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.
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.

void atomicInc(ref scope shared(int) x);

int x;
atomicInc(x); // <-- perfectly safe

That's a boring example, but I shouldn't need to write a second copy of the
function when it is threadsafe.

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,


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.

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.


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.

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 does, because DRY and mitigating redundancy.

it

> makes no sense to me to have it happen. The entire point
> is for it to be used with @trusted stuff.


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.

And if that's the case, then why
> not just have the cast be explicit and @trusted like it normally would be?
>

Because you've overlooked the 99% case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20190623/123e6164/attachment.html>