Steven Schveighoffer wrote:
On Thu, 10 Feb 2011 15:22:48 -0500, Don <nos...@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
http://d.puremagic.com/issues/show_bug.cgi?id=3659
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 known.
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?
