struct S6221 { int num; } S6221 blah6221() { return S6221(1); } void boo6221(const ref S6221 rhs) {} void bug6221() { boo6221(blah6221()); // fails; not callable with argument types S6221 } This is a particular problem because of opCmp: struct S { int num; int opCmp(const ref S rhs) const { if (num < rhs.num) return -1; else if (num > rhs.num) return 1; return 0; } } S blah() { return S(1); } void bug() { bool b1 = blah() < S(45); // OK bool b2 = S(45) > blah(); // fails }
I think this bug is invalid. A value-type return is an rvalue, and Andrei has made it very clear in his posts and in TDPL that rvalues cannot be bound to const ref parameters. I think his reasoning is that this ability was a mistake in C++, though I haven't gotten consistent answers as to why. However, I cannot tell you what you are supposed to do -- I had thought that auto ref was supposed to take care of this (i.e. you could bind an rvalue to an auto ref parameter), but I've gotten mixed interpretations from Andrei on how it is supposed to work. The fact that it works with opCmp in one direction is I think a relaxation of the rules, because struct returns would be near useless if you couldn't call any methods on them. I'll leave this up to Andrei or Walter to mark it invalid, in case I'm wrong.
(In reply to comment #1) > I think this bug is invalid. A value-type return is an rvalue, and Andrei has > made it very clear in his posts and in TDPL that rvalues cannot be bound to > const ref parameters. I think his reasoning is that this ability was a mistake > in C++, though I haven't gotten consistent answers as to why. That's probably true. But that has consequences. We can't discard that C++ behaviour and yet keep the C++ behaviour of using const ref in operator overloads: > The fact that it works with opCmp in one direction is I think a relaxation of > the rules, because struct returns would be near useless if you couldn't call > any methods on them. This is a serious problem. opCmp behaviour MUST be symmetrical. S foo() {...} S x; x > foo() foo() < x foo() > foo() If any of these compile, they must all compile. As far as I can tell, a 'const ref' parameter on pretty much any operator overload, is a bug. In fact it's difficult to come up with _any_ scenarios where 'const ref' makes sense.
Like I said, I don't know what the right solution is. Previously I thought auto ref was the solution, but I'm not so sure. I agree operators need to accept rvalues, but I don't think const ref will be acceptable to Andrei. If this bug report was changed to "it should be possible to pass both rvalues and lvalues to operators," it would be a valid bug.
Shouldn't opCmp be relaxed like opEquals in bug 3659?
(In reply to comment #4) > Shouldn't opCmp be relaxed like opEquals in bug 3659? It is indeed the same issue. But I'm not convinced by the proposed solution in bug 3659. We don't need more options -- we just need one GOOD one. IMHO, this is *the* remaining black hole in the language. We have a zoo of parameter passing options -- in, inout, out, ref, const ref, auto ref -- and yet it's not possible to express the most basic parameter passing option: "I want read-only access from this value, and I give the compiler freedom to pass it as efficiently as possible."
I think that const auto ref does the trick, assuming that that works with opCmp, but for some reason, it only works with templated functions at the moment. I thought that it was supposed to work with non-templated functions as well. If it doesn't, then I guess that the forced solution is to define an overload which takes a const ref and one which takes the argument by value. It would be much simpler if const ref could take a temporary, but Andrei is dead set against that solution. A related issue is the fact that boo6221(S6221(5)); compiles while boo6221(blah6221()); does not, since (for reasons that I've never understood) a struct literal is considered an lvalue: issue# 5889.
This is now possible to do, using `-preview=in` and `in` instead of `const ref`, with DMD > 2.094.0.