[dmd-beta] D 2.059 beta 4

[Jonathan M Davis]

On Monday, April 09, 2012 18:02:41 Nick Sabalausky wrote:
> From: "David Nadlinger" <code at klickverbot.at>
> 
> > On 9 Apr 2012, at 21:18, Nick Sabalausky wrote:
> >> I'm getting an ICE as a regression:
> >> 
> >> mtype.c:4472: StructDeclaration* TypeAArray::getImpl(): Assertion `impl'
> >> failed.
> >> 
> >> DustMite-int it now...
> > 
> > Try directly instantiating the AssociativeArray template – this way you
> > should be able to see the underlying error message.
> 
> Thanks. At one point, it's trying to pass a const(MyStruct) to
> MyStruct.opEquals, and I forgot to keep the const overload when 2.059 is
> detected (ATM I only have the the new non-const non-ref opEquals when 2.059
> is detected). So that's why I'm not getting that ICE in 2.058.
> 
> I'm not going to end up *also* needing "const non-ref" and/or "non-const
> ref" versions too, am I? I think my brain's turning to mud now...

Look at the Kenji's c omments on 
http://d.puremagic.com/issues/show_bug.cgi?id=7864

I expect that they apply to opEquals as well as opCmp. That being the case, 
the proper overloads would be

bool opEquals(const S rhs) const {}
bool opEquals(const ref S rhs) const {}

and the non-ref version should actually be able to call the ref version 
without causing infinite recursion. The lack of const on the non-ref version 
causes issues with structs which hold reference types.

All in all, this is way too messy. Bearophile's suggestion of using const auto 
ref will probably work though as long as you template the function (since auto 
ref doesn't currently work with non-templated functions).

- Jonathan M Davis