How will we fix opEquals?
schveiguy at yahoo.com
Thu Feb 10 14:41:56 PST 2011
On Thu, 10 Feb 2011 16:34:57 -0500, Don <nospam at nospam.com> wrote:
> Steven Schveighoffer wrote:
>> On Thu, 10 Feb 2011 15:22:48 -0500, Don <nospam at nospam.com> wrote:
>>> A tiny compromise which could be made, is to silently add 'const' to
>>> any class opEquals declaration, even if not present in the source.
>>> That way, simple use cases would still compile without complaint.
>>> (As long as only a single, precisely defined opEquals signature is
>>> permitted, I think any other signature should be flagged as an error
>>> -- but it could be converted to the correct signature, instead).
>>> Dunno if this would be worth it, though.
>> I think then we get back to
> No, we don't, because that issue applies to structs, not classes. For
> classes, it has to go in the vtable, so the precise signature must be
What I meant was, if the compiler complains that some specific function x
has the wrong signature, you have assumptions the compiler is making that
may not be correct. To me, opEquals is special, but it's still a regular
function, and putting extra limitations is sure to ferret out some use
case where the limitation is invalid.
bool opEquals(int x) const
to be a perfectly valid signature in a class.
>> Would it be possible to define a construct that says "you can override
>> this function, but you cannot add any new overloads"? like a @precise
>> or something like that? Then we can have a real feature to use for
>> things like this. Sort of like final, but you're not cutting off the
>> virtual function path, just restricting the API to be exactly what you
>> specify. That way someone cannot accidentally create a non-const
>> opEquals and generate a hidden function exception. Although, anyone
>> worth his salt will test the opEquals, which dmd forces through
>> .opEquals(const(Object), const(Object)).
> For sure that could be done. But again -- does it add much value?
Not really, I don't think it's that big a problem to begin with. If you
try comparing two objects and you didn't define your signature right, then
you get a hidden func error, since they all go through .opEquals(...)
which casts everything to Object (should be const(Object) ). So the only
way this gets out is if you never test the code you wrote.
More information about the Digitalmars-d