On Thursday 10 February 2011 12:22:48 Don wrote: > Steven Schveighoffer wrote: > > On Thu, 10 Feb 2011 10:19:50 -0500, Andrei Alexandrescu > > > > <seewebsiteforem...@erdani.org> wrote: > >> On 2/10/11 2:58 AM, Peter Alexander wrote: > >>> On 10/02/11 8:19 AM, Don wrote: > >>>> Andrei once stated a worthy goal: as far as possible, const should be > >>>> opt-in: it should be possible to code without requiring const on > >>>> everything. > >>>> > >>>> opEquals() is in conflict with this, since it is a member function of > >>>> Object. > >>>> > >>>> (1) If it is a const member function, then it will have a viral effect > >>>> on all objects -- any function called by opEquals will have to be > >>>> marked > >>>> const. > >>>> (2) If it is not const, then const objects cannot be compared! > >>>> > >>>> Currently, it's not const, but the problem isn't visible because of > >>>> compiler bug 5080. (Same problem applies to opCmp). > >>>> > >>>> How will we break this dilemma? > >>> > >>> It's not possible. > >> > >> It is, in fact, possible. We can define two opEquals overloads, for > >> const and non-const. By default, the non-const version forwards to the > >> const one. > > > > 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). > > Dunno if this would be worth it, though.
I'd argue that silently changing function signatures is a _bad_ idea. And when they actually try and do something which would violate the constness of the function, they're going to be left scratching their head as to why a non-const function is getting complaints about const. In general, D has opted to _not_ do things silently. C++ did a fair bit of it in certain places (albeit not with const), and it's caused problems. I don't think that this would be as big a problem, but I still don't think that it's a good idea. Really, while it's reasonable to not force D programmers to use const all over the place, I do _not_ think that it's reasonable for a D programmer to not be aware of const. And since opEquals, opCmp, toHash, and toString/writeTo all need to be const, the programmer is just going to have to deal with that fact. And having to put const on a few functions is likely to cause less pain than figuring out why they're getting errors with regards to const when they never use const anywhere. - Jonathan M Davis
