Possible way to achieve lazy loading with const objects

[Steven Schveighoffer]

On Thu, 29 Sep 2011 11:45:18 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 9/29/11 8:38 AM, Steven Schveighoffer wrote:
>> On Thu, 29 Sep 2011 11:09:13 -0400, Christophe
>> <travert at phare.normalesup.org> wrote:
>>
>>> "Steven Schveighoffer" , dans le message (digitalmars.D:145738), a
>>>>> It is always possible for a non-const version of opEqual to forward  
>>>>> to
>>>>> the const version, so people willing to use a const version do not  
>>>>> have
>>>>> to define a non-const version.
>>>>
>>>> Again, you still need to define both, this is not a good situation.
>>>
>>> No, I didn't express myself correctly. The non-const version should
>>> forward to the const version *by default*.
>>
>> Fine, but if you want to define a non-const version that *doesn't* call
>> the const version, you have to define both. So even if you *don't* want
>> to deal with const, you still do. I should have been clearer, sorry.
>>
>> Note that the compiler currently calls a global method which accepts two
>> non-const Objects. In order for it to support both const and mutable
>> versions, it would have to have 4 different functions.
>>
>> I really don't think all this complexity is worth the benefit. Just
>> learn to use const properly, or don't use the operator system to do
>> comparisons. Object.opEquals should be const.
>
> If we make this change we're liable to break all code that defines  
> opEquals for classes.
>
> Two versions should be enough: const/const and mutable/mutable, which by  
> default forwards to const/const. Old code will run unchanged at a slight  
> efficiency cost due to forwarding. Since it didn't previously work for  
> const anyway, no harm done.
>
> New code gets to only override the const/const version.
>
> Where is this wrong?

class MyExistingClass
{
   string name;
   this(string n) { name = n;}
   bool opEquals(Object other)
   {
      if(auto x = cast(MyExistingClass)other)
      {
         return x.name == name;
      }

      return false;
   }
}

void main()
{
   auto mec = new MyExistingClass("foo".idup);
   auto mec2 = new MyExistingClass("foo".idup);

   const mec_const = mec;
   const mec2_const = mec2;

   assert(mec == mec2);
   assert(mec_const == mec2_const); //???
}

So what does the second assert do?  With the current compiler, it should  
fail to compile (not sure if it does, I know there was a bug where it used  
to pass).

The current Object has a default equality comparison that checks for  
identity.  Is that what the default const version would do?  In that case,  
the first assert passes, whereas the second assert fails.

If we make the default const opEquals throw, then this breaks existing  
code for classes which *don't* implement opEquals.

Any way you slice it, code is going to break.  I'd rather it break in the  
compile phase then silently misbehave later.

-Steve