Optional monitors suggestion

[David Nadlinger via Digitalmars-d]

On Sunday, 18 May 2014 at 10:33:53 UTC, Andrei Alexandrescu wrote:
> Maybe I misunderstood - I thought the change preserves 
> semantics. -- Andrei

There are two layers to the changes discussed in this thread. The 
first is to remove __monitor from Object. This is something I 
think we all agree on.

Now there are two possibilities for what to do when a user tries 
to synchronize on an instance that does not have a monitor field. 
One option would be to just fall back on a global lock lookup 
table of some sorts. This is what Yuriy's proposal does, and 
indeed preserves language semantics at the expense of a "silent" 
slowdown in these cases. The other is to outright forbid 
synchronizing on such objects. This is a small breaking change, 
but arguably the cleaner solution.

If we didn't have to worry about being backwards compatible, I'd 
definitely argue for the second solution. Java compatibility is 
not a very strong argument in my opinion. First, porting a Java 
application 1:1 is asking for  performance hazards (w.r.t. GC, 
...) anyway. Second, the no-synchronized-by-default design allows 
for clear error messages that immediately suggest the correct fix 
(add an attribute to the class declaration), and for mechanical 
porting, Java classes could just be translated to 
"@synchronizable class" or whatever.

David