Bug 21033 – enhancement: allow assign to field when the shared owing object has been locked already without cast

``` 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; ``` 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. I think if we enhance the compiler on this simple example, it may cover ~90% of such use case without the need of the ugly cast.

Created attachment 1797 enhancement: allow assign to field when the shared owing object has been locked already without cast

hasIndirections!SysTime is true, so in theory `time` can't have `shared` cast away safely. See issue #24269. However, it looks like the only indirection is to immutable data: long _stdTime; Rebindable!(immutable TimeZone) _timezoneStorage; So actually the cast might be safe.

This can be done only for value types, shared and immutable data. For thread local mutable reference types lock doesn't provide thread safety, because you escape thread local data into shared context. What you ask can't be for all reference types. Whether it can be done for SysTime is a SysTime's problem.

(In reply to anonymous4 from comment #3) > What you ask can't be for all reference types. can't be done

You can store Duration: class A { Duration unixTime; synchronized void setTime(ref SysTime t) { unixTime = t-epoch; } synchronized SysTime getTime() { return epoch+unixTime; } }