```
import std.datetime;

class A {
        SysTime time;
}

void main() {
        shared A a = new A();
        SysTime time;
        a.time = time;
}
```

Error: template std.datetime.systime.SysTime.opAssign cannot deduce function from argument types !()(SysTime) shared, candidates are:
/usr/include/dmd/phobos/std/datetime/systime.d(659,17):        opAssign()(auto ref const(SysTime) rhs)

On Friday, 10 July 2020 at 02:59:56 UTC, mw wrote:
> Error: template std.datetime.systime.SysTime.opAssign cannot deduce function from argument types !()(SysTime) shared, candidates are:
> /usr/include/dmd/phobos/std/datetime/systime.d(659,17):        opAssign()(auto ref const(SysTime) rhs)

of course, better without casting.

On Friday, 10 July 2020 at 03:01:20 UTC, mw wrote:
> On Friday, 10 July 2020 at 02:59:56 UTC, mw wrote:
>> Error: template std.datetime.systime.SysTime.opAssign cannot deduce function from argument types !()(SysTime) shared, candidates are:
>> /usr/include/dmd/phobos/std/datetime/systime.d(659,17):        opAssign()(auto ref const(SysTime) rhs)
>
> of course, better without casting.

looks like we still have to cast:

https://forum.dlang.org/post/lehfwimpolhrmkfmtacn@forum.dlang.org


as of 2020, sigh.

On Thursday, July 9, 2020 9:01:20 PM MDT mw via Digitalmars-d-learn wrote:
> On Friday, 10 July 2020 at 02:59:56 UTC, mw wrote:
> > Error: template std.datetime.systime.SysTime.opAssign cannot
> > deduce function from argument types !()(SysTime) shared,
> > candidates are:
> > /usr/include/dmd/phobos/std/datetime/systime.d(659,17):
> > opAssign()(auto ref const(SysTime) rhs)
>
> of course, better without casting.

Unless you're dealing with a primitive type that works with atomics, you pretty much always have to cast when using shared (the only real exception being objects that are specifically designed to work as shared and do the atomics or casting internally for you). In general, when operating on a shared object, you need to protect the section of code that's operating on it with a mutex and then temporarily cast away shared to operate on the object as thread-local. It's then up to you to ensure that no thread-local references to the shared data escape the section of code protected by the mutex (though scope may help with that if used in conjunction with -dip1000).

- Jonathan M Davis

On Friday, 10 July 2020 at 05:12:06 UTC, mw wrote:
> looks like we still have to cast:
> as of 2020, sigh.

Why not?

On Friday, 10 July 2020 at 08:48:38 UTC, Kagamin wrote:
> On Friday, 10 July 2020 at 05:12:06 UTC, mw wrote:
>> looks like we still have to cast:
>> as of 2020, sigh.
>
> Why not?

Because cast is ugly.

I've also tried this:
```
class A {
        SysTime time;
        synchronized setTime(ref SysTime t) {
                time = t;
        }
}

void main() {
        shared A a = new A();
        SysTime time;
        a.setTime(time);
}
```

Same Error: template std.datetime.systime.SysTime.opAssign cannot deduce function from argument types !()(SysTime) shared, candidates are:
/usr/include/dmd/phobos/std/datetime/systime.d(659,17):        opAssign()(auto ref const(SysTime) rhs)

However, we have a lock on the owning shared object, still we need cast to make it compile:
```
      cast()time = t;
```

On Friday, 10 July 2020 at 17:18:25 UTC, mw wrote:
> On Friday, 10 July 2020 at 08:48:38 UTC, Kagamin wrote:
>> On Friday, 10 July 2020 at 05:12:06 UTC, mw wrote:
>>> looks like we still have to cast:
>>> as of 2020, sigh.
>>
>> Why not?
>
> Because cast is ugly.
>
> I've also tried this:
> ```
> class A {
>         SysTime time;
>         synchronized setTime(ref SysTime t) {
>                 time = t;
>         }
> }
>
> void main() {
>         shared A a = new A();
>         SysTime time;
>         a.setTime(time);
> }
> ```
>
> Same Error: template std.datetime.systime.SysTime.opAssign cannot deduce function from argument types !()(SysTime) shared, candidates are:
> /usr/include/dmd/phobos/std/datetime/systime.d(659,17):        opAssign()(auto ref const(SysTime) rhs)
>
> However, we have a lock on the owning shared object, still we need cast to make it compile:
> ```
>       cast()time = t;
> ```

Shall I log an enhancement bug for this?

On 7/10/20 1:18 PM, mw wrote:
> On Friday, 10 July 2020 at 08:48:38 UTC, Kagamin wrote:
>> On Friday, 10 July 2020 at 05:12:06 UTC, mw wrote:
>>> looks like we still have to cast:
>>> as of 2020, sigh.
>>
>> Why not?
> 
> Because cast is ugly.
> 
> I've also tried this:
> ```
> class A {
>          SysTime time;
>          synchronized setTime(ref SysTime t) {
>                  time = t;
>          }
> }
> 
> void main() {
>          shared A a = new A();
>          SysTime time;
>          a.setTime(time);
> }
> ```
> 
> Same Error: template std.datetime.systime.SysTime.opAssign cannot deduce function from argument types !()(SysTime) shared, candidates are:
> /usr/include/dmd/phobos/std/datetime/systime.d(659,17): opAssign()(auto ref const(SysTime) rhs)
> 
> However, we have a lock on the owning shared object, still we need cast to make it compile:
> ```
>        cast()time = t;
> ```
> 

Mark your setTime as shared, then cast away shared (as you don't need atomics once it's locked), and assign:

synchronized setTime(ref SysTime t) shared {
    (cast()this).time = t;
}

-Steve

On Friday, 10 July 2020 at 17:35:56 UTC, Steven Schveighoffer wrote:
> Mark your setTime as shared, then cast away shared (as you don't need atomics once it's locked), and assign:
>
> synchronized setTime(ref SysTime t) shared {
>     (cast()this).time = t;
> }

I know I can make it work by casting, my question is:

we had a lock on the owning shared object already, WHY we still need the cast to make it compile.

On 7/10/20 2:30 PM, mw wrote:
> On Friday, 10 July 2020 at 17:35:56 UTC, Steven Schveighoffer wrote:
>> Mark your setTime as shared, then cast away shared (as you don't need atomics once it's locked), and assign:
>>
>> synchronized setTime(ref SysTime t) shared {
>>     (cast()this).time = t;
>> }
> 
> I know I can make it work by casting, my question is:
> 
> we had a lock on the owning shared object already, WHY we still need the cast to make it compile.
> 

Because locking isn't that simple. There is no "one size fits all" locking scheme that can be enforced by the language. So the best option is to make sure if you shoot yourself in the foot, it's your fault, and not D's.

-Steve