On 4/4/18 1:32 AM, Jonathan M Davis wrote:
On Wednesday, April 04, 2018 00:49:10 Andrei Alexandrescu via Digitalmars-d
I'm working on a simple older idea to get it out of the way in
preparation for the more difficult DIPs to come:


This is not officially reviewable yet, but conveys the gist and could
use some early feedback. Any insight will be appreciated.

Two things I can think of after quickly going over it:

1. While issues with attributes and Object are discussed, the fact that
Object.opEquals requires casting away const and effectively puts a hole in
the type system is not mentioned. I don't know that it's all that critical
to mention it given all of the other issues, but it certainly affects how
overloading opEquals is going to need to be implemented for ProtoObject.
Presumably, the free function version of opEquals will need to be templated
with an overload that takes classes which are not derived from Object,
allowing opEquals to use whatever attributes are appropriate.

Yes, and at some point, we should deprecate the casting version, meaning your Object that doesn't define a const opEquals will stop compiling.

2. What happens if you put synchronized on a member function when the class
is not derived from ProtoObjectWithMonitor? I would assume that it would be
an error, but the DIP doesn't say.

Error. No place to allocate the monitor.


Reply via email to