Synchronized classes have no public members

[Minas Mina via Digitalmars-d]

On Tuesday, 13 October 2015 at 08:55:26 UTC, Benjamin Thaut wrote:
> 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.

I agree that synchronized classes / functions that not that 
useful.

But synchronized statements, to me, make the intention of locking 
explicit.

Maybe the internal monitor could be removed (with synchronized 
classes / functions as well), and allow synchronized() {} to be 
called on Lock objects, that essentially locks them at the 
beginning and unlocks them at the end.