Synchronized classes have no public members

[Dicebot via Digitalmars-d]

On Thursday, 15 October 2015 at 17:10:23 UTC, Steven 
Schveighoffer wrote:
> You can do both of these with synchronized statements, 
> mutex.unlock works and you can use with a condition variable.
>
> As I said before, with the Guard lock, you have more room for 
> error, and visually the lock is better identified with a 
> synchronized statement.

There is no argument it looks nicer but it is a dedicated 
language feature for a minor syntax sugar over a feature that is 
almost never used in modern idiomatic concurrent code. Explicit 
locking in application code is rather old school, same as the 
notion that blindly adding more threads to existing OOP program 
helps to improve performance.

It isn't bad to have it but don't forget Andrei's words about 
constant sum of language complexity - we could have had something 
more useful in totally different domain instead of it.