Synchronized classes have no public members

[Benjamin Thaut via Digitalmars-d]

On Tuesday, 13 October 2015 at 07:17:20 UTC, Jonathan M Davis 
wrote:
>
> Ultimately, I think that we're better off with TDPL's 
> definition of synchronized classes than the synchronized 
> functions that we have now, so I do think that the change 
> should be made. However, I also think that synchronized classes 
> as TDPL describes are limited enough to be of questionable 
> usefulness. Stripping off the outer layer of shared is unlikely 
> to be sufficient in all but basic cases (and synchronized 
> classes can't do any better than that, I don't think), meaning 
> that you're likely going to have to cast away shared to do much 
> with shared anyway, in which case, having a synchronized class 
> loses at least some of its value. It can still encapsulate 
> shared (which is good), but it doesn't necessarily make it much 
> easier or safer to use.
>
> - Jonathan M Davis

I have to agree here. I think synchronized classes are of very 
little use, especially because they don't "cast away" shared in a 
useful way. It still has to be done manually. I think we should 
remove them. Synchronized methods should also be removed in my 
eyes. Making each and every object bigger by one pointer just for 
the sake of a few synchronized methods doesn't seem to be a good 
trade off to me. The entire synchronized methods give the user 
the feeling that he simply slaps synchronized on his class / 
method and then its thread safe and he doesn't have to care about 
threads anymore. In the real world this is far from true however. 
So synchronized methods and classes just give a false sense of 
thread safety and should rather be removed.