Synchronized classes have no public members

[Jonathan M Davis via Digitalmars-d]

On Thursday, 15 October 2015 at 14:28:00 UTC, Andrei Alexandrescu 
wrote:
> On 10/14/15 9:24 AM, Jacob Carlborg wrote:
>> On 2015-10-13 14:56, Dicebot wrote:
>>
>>> I still have no idea why I would ever use `synchronized` (any 
>>> automatic
>>> thread synchronization is harmful in my opinion) so change 
>>> itself is
>>> irrelevant. But it may break quite some old Java-liked 3d 
>>> party code for
>>> no benefit and that would be annoying.
>>
>> Like DWT :)
>
> That may be worrisome. Any information on how many are using 
> DWT, and how badly it would break if we pulled the change?
>
> If we assess there's too much breakage, we can define a DIP and 
> make the check opt-in via a flag -dipNN.

The current behavior needs to be deprecated first regardless. We 
shouldn't just throw a switch and make it illegal to access 
member variables of a synchronized class. If we start with a 
deprecation message about it and only move to making it illegal 
later, then it really shouldn't matter much what existing code is 
doing.

A switch makes sense if we intend to experiment with this rather 
than necessarily being the case that we want to go in this 
direction. But even then, we'd have to either deprecate the 
current behavior at some point or just break everyone's code who 
hadn't bothered to use the switch.

But given the general hostility to synchronized in this thread 
(for whatever that's worth given the relatively few people 
involved), it could very well be that future discussions on 
shared/synchronized would lean towards just axing synchronized, 
making any changes we do to it now moot. Still, from a 
correctness standpoint, I think that it's pretty clear that 
synchronized classes are better than synchronized functions.

- Jonathan M Davis