On Thursday, 15 October 2015 at 10:11:06 UTC, Andrei Alexandrescu
wrote:
Yes, and I am saying that it doesn't justify presence of
`synchronized`
keyword in the language at all, being historical legacy
misfeature.
For a while we were of the opinion that we should let
"synchronized" and "shared" be and move on with alternative
features. Now we believe an incomplete language definition is
damaging the language as a whole so we better make them fully
defined and useful within their charter.
Lock-based synchronization has plenty of good uses and the
scope locking defined by "synchronized" covers a large useful
subset of it. We need to make it usable safely and without
contortions, and this particular PR is a step along that way.
It's not a huge priority but since Andrej has only done the
work, the main concern left is breakage of existing code,
albeit much of that is incorrect or unnecessarily unsafe.
You are absolutely correct that incomplete definition is
damaging. I can also agree with "plenty of uses" but hardly with
"plenty of good uses" though. There are many situations of course
where efficient concurrency is not critical and one can go away
with straightforward mutex approach. But providing such semantics
as language builtin implies it is encouraged and "official"
approach and that is rather bad :(
To be honest I'd prefer it to go in "not really deprecated but
pretend it doesn't exist" trash bin like scope storage class is.
the main concern left is breakage of existing code, albeit much
of that is incorrect or unnecessarily unsafe.
This is a bit more delicate issue. This code is only incorrect
and/or unsafe if used in multi-threaded environment and those
fields are actually accessed. There isn't anything broken with
such code per se. I agree it should be fixed (with a proper slow
deprecation phase) but I am not happy about it.
