D Language Foundation Monthly Meeting Summary for November 2022

[Adam D Ruppe]

On Thursday, 12 January 2023 at 11:47:26 UTC, Mike Parker wrote:
> Andrei asked Razvan about the status of [the ProtoObject 
> DIP](https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1042.md). Razvan said that Adam Ruppe had raised some valid complaints in the DIP's pull request thread, and those were reinforced in the community review.
> [...]
> Andrei thinks it's worth making an effort to resolve any issues 
> the proposal has.

What I'd recommend doing is migrating the existing Object to 
match the desired capabilities.

The biggest complaint people have that has no real solution in 
the existing language is the unconditional presence of the 
monitor field. I actually think you could infer this without too 
much of a breaking change; the presence of a `synchronized(this)` 
in the same module as the class definition could infer its 
necessity and add it to the type (this would also cover 
`synchronized` classes and methods, of course), but in other 
modules you couldn't be so sure (since they can be compiled 
separately).

This would break anyone who uses synchronized(random_object) 
(which includes me btw) but the migration would be so simple 
(change the type) and it'd retain compatibility with old 
compilers so I think it'd be a minimum amount of pain.

Other option is to just remove it and require everyone to use an 
explicit Mutex field, which also has a number of advantages, but 
is more invasive and means removing synchronized classes and 
methods as language features entirely.

Among other complaints in that dip were opEquals, which is 
already fixed (and tbh could just be removed but i think it is 
fairly harmless to keep), factory which is slated for removal 
already, opCmp (which currently throws if you call it! so it 
isn't used by anything and could be simply removed), and opHash 
which recently was subjected to a random breaking change anyway 
(and a bad one that didn't achieve anything, but it shows that 
breakage is obviously on the table), so everything else already 
is being addressed in Object itself.