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.
