Synchronized classes have no public members

[Dicebot via Digitalmars-d]

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.