Optional monitors suggestion

[Andrei Alexandrescu via Digitalmars-d]

On 9/8/14, 2:10 AM, Andrej Mitrovic wrote:
> On Thursday, 22 May 2014 at 17:25:30 UTC, Steven Schveighoffer wrote:
>> A possible path is to introduce the change, but put @monitor on
>> Object. This will allow all current code to compile as-is.
>>
>> Then users who are concerned about their code being affected would be
>> able to remove @monitor from Object, recompile druntime and phobos
>> (once we make it work) and allow people to see how their code breaks
>> without being left hanging (the shipping compiler would still have
>> @monitor).
>>
>> Then eventually, we can remove @monitor from Object, and users who
>> still wish to force @monitor on Object can do so (recompile druntime
>> and phobos with @monitor added).
>
> This sounds like a reasonable deprecation stage.
>
> Anyway it seems like we're all mostly on the same page here (remove the
> monitor) except the final part: potential implicit performance penalty
> vs code breakage after a deprecation stage. Either way we chose there's
> a pull ready[1] that's going stale.
>
> Can we get an update from both Andrei & Walter to get going with this?
>
> [1]: https://github.com/D-Programming-Language/dmd/pull/3547

I'm in favor of getting rid of the monitor field. I'm not sure I 
understand whether @monitor introduces a field or just an entry in the 
hashtable. FWIW we could do this for backward compatibility: objects 
without @monitor use the hashtable, and those with @monitor use a field.

Andrei