On Monday, April 09, 2012 18:02:41 Nick Sabalausky wrote: > From: "David Nadlinger" <[email protected]> > > > 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 _______________________________________________ dmd-beta mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-beta
