Bug 9218 – [2.061] Correct signature of struct opCmp no longer accepts enum structs

This code worked fine in 2.060, errors with 2.061 beta 1: struct A { enum zero = A(); // Error: A() is not an lvalue int opCmp(const ref A a) const //int opCmp(A a) { return 1; } } void main() { A a; auto b = a > A.zero; assert(typeid(a).xopCmp !is null); } Obviously I could use a different signature for opCmp (e.g. the one I commented out) but then the assert below will fail, as only the correct signature of opCmp is accepted. Fixing either this bug or http://d.puremagic.com/issues/show_bug.cgi?id=8561 would be good enough for me.

Since it's a struct you can also use: int opCmp()(auto const ref A a) const Otherwise I don't think this is a rejects-valid, it's a documentation issue. Struct literals (manifests included) are no longer lvalues in 2.061, this is by design.

(In reply to comment #1) > Since it's a struct you can also use: > > int opCmp()(auto const ref A a) const This fails the assert. > Otherwise I don't think this is a rejects-valid, it's a documentation issue. > Struct literals (manifests included) are no longer lvalues in 2.061, this is by > design. Then this bug highlights what a bad set of design decisions it was to both make struct literals not lvalues AND require the proper opCmp signature to function only for lvalues.

Tested on DPaste, this code runs successfully with DMD 2.x Git (UDA beta build) (supposedly updated daily) both in 32 and 64 bits. http://dpaste.dzfl.pl/fork/54f9a9e5

(In reply to comment #3) > Tested on DPaste, this code runs successfully with DMD 2.x Git (UDA beta build) > (supposedly updated daily) both in 32 and 64 bits. > > http://dpaste.dzfl.pl/fork/54f9a9e5 I haven't been able to open that link. In general, I think it's better to just paste code examples inline here.

Solving the rvalue reference problem, Issue 9238, is the correct way to resolve this. Unfortunately, I think it would be too disruptive to add such a large change with potential side effects in at the last minute, so I'd like to defer this to the next version. In the meantime, you can workaround by providing an overload: int opCmp(const A a) { return 1; }

(In reply to comment #4) > I haven't been able to open that link. The code: struct A { enum zero = A(); // Error: A() is not an lvalue int opCmp(const ref A a) const //int opCmp(A a) { return 1; } } void main() { A a; auto b = a > A.zero; assert(typeid(a).xopCmp !is null); } test.d(3): Error: A() is not an lvalue

I worked around this for now by adding this overload: int opCmp(const A a) const { return opCmp(a); } This seems to work because the compiler prefers the const ref version to the const version.

(In reply to comment #4) > (In reply to comment #3) > > Tested on DPaste, this code runs successfully with DMD 2.x Git (UDA beta build) > > (supposedly updated daily) both in 32 and 64 bits. > > > > http://dpaste.dzfl.pl/fork/54f9a9e5 > > I haven't been able to open that link. In general, I think it's better to just > paste code examples inline here. It's the code of the original problem description. I copy it in DPaste because it offers a very convenient way to test it with the three main D compilers in both 32 and 64 bits without having to install these compilers on one's own computer. DPaste offers the 2.060 compilers as well as the latest overnight version of the main branch, so it's quite convenient for quick testing.

Ok, that workabout is not quite complete (perhaps this is a different bug now?). While it solves the code in the original comment, this code doesn't work: struct A { enum A zero = {}; // Note the difference here int opCmp(const ref A a) const { return 1; } int opCmp(const A a) const { return opCmp(a); } } void main() { A a; auto b = a >= A.zero; //The error is now here! test.d(21): Error: A() is not an lvalue auto c = a > a; assert(typeid(a).xopCmp !is null); typeid(a).xopCmp(&a, &a); } Why would enum A zero = A(); work but enum A zero = {}; not work? Is it safe (in terms of inadvertent GC usage) to use A() instead of {}?

(In reply to comment #9) > Ok, that workabout is not quite complete (perhaps this is a different bug > now?). While it solves the code in the original comment, this code doesn't > work: > [snip] > > Why would enum A zero = A(); work but enum A zero = {}; not work? Is it safe > (in terms of inadvertent GC usage) to use A() instead of {}? This is a different bug which is unrelated to the ref-non-ref overloading. I opened a new bug report. Issue 9293 - enum struct with StructInitializer reports weird error So this is an invalid bug, because: (In comment #1) > Struct literals (manifests included) are no longer lvalues in 2.061, this is by design.

We still need to address the rvalue ref issue, but at the moment this is invalid because it's by design.