Optional monitors suggestion

[Yuriy via Digitalmars-d]

On Wednesday, 14 May 2014 at 13:53:51 UTC, Damian Day wrote:
> These would be breaking changes. I see the benefit but...
Breaking, only if someone used to define __monitor in his class. 
Which is kinda weird, and according to docs (identifiers starting 
with __ should are reserved). Or if someone used to access 
__monitor field of something, which is also kinda weird. 
Otherwise, no breaking changes here.

> If the compiler recognizes the class using synchronized, it 
> could
> use a little magic and add a monitor variable itself, this would
> not cause any breaking change.
I guess it would need a whole lot of magic, since synchronized() 
is normally used outside of class and even its module, except for 
synchronized(this) or smth. And adding members in compile-time to 
classes defined in not_current_module sounds like a bad idea.
However, compiler could do some little magic, adding __monitor to 
a class, if it can prove that synchronized is used in the same 
module where class is defined.
Another however, i'm not sure if such optimization is even worth 
thinking of, since you still can sync on any class regardless it 
defines __monitor or not.