On Saturday, 22 June 2019 at 08:36:18 UTC, Walter Bright wrote:
> On 6/22/2019 1:03 AM, Manu wrote:
>> Your code snippet is incomplete; show the implementation of passToThread()...
>
> Doesn't make any difference.

Oh, came on!

/P

On Friday, 21 June 2019 at 18:11:38 UTC, Meta wrote:
> @trusted is allowed to do whatever it wants internally, as long as it provides a *safe* interface. I believe that's what Manu's getting at in regards to his @safe/@trusted distinction in regards to threading.

Concurrency is indeed safe with that interface, so there's no reason to assume that it doesn't happen, and implicit conversion from thread local to shared is illegal.

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

On 22.06.19 22:32, Jonathan M Davis wrote:
> 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?

Why would @safe code not benefit? Manu's use case is @safe code calling into a @trusted library.

On Saturday, June 22, 2019 2:52:33 PM MDT Timon Gehr via Digitalmars-d wrote:
> On 22.06.19 22:32, Jonathan M Davis wrote:
> > 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?
> Why would @safe code not benefit? Manu's use case is @safe code calling into a @trusted library.

Because if all of the code is @safe, then the fact that it was converted to scope shared gains you nothing. It's not really shared across threads, and it doesn't enable any useful operations. The only time that you can do anything extra with it is when you then have @trusted code within the @safe code, and the @trusted code then does something like temporarily pass a reference to another thread. And if the only time that the implicit conversion to scope shared is actually useful is when you have @trusted code, then why not just have the cast be explicit and @trusted?

- Jonathan M Davis

On Sat., 22 Jun. 2019, 6:40 pm Walter Bright via Digitalmars-d, < digitalmars-d@puremagic.com> wrote:

> On 6/22/2019 1:03 AM, Manu wrote:
> > Your code snippet is incomplete; show the implementation of
> passToThread()...
>
> Doesn't make any difference.
>

It really does. If you can't get the reference to another thread, then everything you say is moot, and that's the whole point.

Show how to escape the pointer when it is scope...?

>

On Sat., 22 Jun. 2019, 6:40 pm Walter Bright via Digitalmars-d, < digitalmars-d@puremagic.com> wrote:

> On 6/22/2019 1:02 AM, Manu wrote:
> > I don't believe `passToThread` could receive a `scope shared(int)*`... can you show an implementation of passToThread?
>
> In @system code you can do whatever you like.
>

If you engage in @system code to distribute across threads, it's a no brainer to expect that code to handle cache coherency measures. It would be broken if it didn't.

>

On Sun., 23 Jun. 2019, 6:32 am Jonathan M Davis via Digitalmars-d, < digitalmars-d@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.

On Sun., 23 Jun. 2019, 7:08 am Jonathan M Davis via Digitalmars-d, < digitalmars-d@puremagic.com> wrote:

> On Saturday, June 22, 2019 2:52:33 PM MDT Timon Gehr via Digitalmars-d wrote:
> > On 22.06.19 22:32, Jonathan M Davis wrote:
> > > 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?
> > Why would @safe code not benefit? Manu's use case is @safe code calling into a @trusted library.
>
> Because if all of the code is @safe, then the fact that it was converted to scope shared gains you nothing. It's not really shared across threads, and it doesn't enable any useful operations.


Not being required to duplicate every threadsafe function is a huge advantage. We went on about this for weeks 6 months ago.

On Saturday, 22 June 2019 at 23:41:49 UTC, Manu wrote:
> 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.

Eh? No. You don't understand const, shared, scope, @safe and @trusted. What authority?