Does D really need something like const&?

[Steven Schveighoffer]

On Fri, 01 Mar 2013 20:37:26 -0500, Era Scarecrow <rtcvb32 at yahoo.com>  
wrote:

> On Saturday, 2 March 2013 at 01:15:20 UTC, Steven Schveighoffer wrote:
>> void main()
>> {
>>     auto t = foo;
>>     t++; // ok
>>     foo++; // Error: foo() is not an lvalue
>> }
>>
>> That should not be an error, or I should at least be able to tell the  
>> compiler "this is NOT an rvalue, even if it seems like one".
>
>   No, foo returns an lValue, however the ++ is likely wrong. The  
> compiler could have an ingrained belief that ++ is an assignment  
> operator meaning it requires an Lvalue, at which point the code is  
> wrong. But ++ is just an operator for the struct, so I don't know.

You are saying opposite things "foo returns an LValue"  "it requires an  
Lvalue, at which point the code is wrong"

Which is it?

I contend that T is an LValue type.  If the compiler can't see that, it  
needs to be told, or it needs to get out of the way.

I just tested a simple "incx()" function that is identical to the  
operator, and it works.  I can even call the operator via  
foo.opUnary!"++"() and it works!  So the compiler is restricting things  
that are trivially circumvented.

Maybe it should be: calling a method of an rvalue, even if that method is  
called via operator overload, should always be allowed.  Any simple field  
access should fail if the rvalue is modified.  So for instance foo.x++  
should fail, but foo++ should work, even if all it does is x++.  Maybe if  
the compiler inlines the code and sees it trivially reduces to a rejected  
case, it can reject it.

-Steve