Michel Fortin wrote:
On 2011-02-10 15:22:48 -0500, Don <nos...@nospam.com> said:
Steven Schveighoffer wrote:
This doesn't work. If you only define one, then you will have
problems with hidden function errors, and/or inconsistencies. For
example, how does .opEquals(Object obj1, Object obj2) know which
version to call?
I think the only true solution is to make it const and call it a day.
-Steve
I fear that you're probably right. The const opEquals must exist,
otherwise the object will be unable to use most functions in Phobos.
And I don't see how it can safely be synthesised from non-const opEquals.
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).
I don't like this idea at all. If the problem is that it's too easy to
hide the underlying function without noticing (no compile-time error),
then fix how the language treats hidden functions (make it a
compile-time error). If opEquals has this problem, other
non-language-defined functions will have it too, and fixing it with a
special case for opEquals will not fix it elsewhere. Not to speak of the
inconsistency it adds.
Oh, I agree. I don't think it's a good idea. It's just the _only_
compromise I could see that would actually work.
