Does D really need something like const&?

[Era Scarecrow]

On Saturday, 2 March 2013 at 01:51:28 UTC, Steven Schveighoffer 
wrote:
> 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"

   Sorry I hate typos. foo returns an Rvalue, therefore is an 
Rvalue.

> 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.

   Anyways, because of how ++ and -- are assumed to basically also 
be opAssign it requires an LValue, at least that's what the 
compiler sees, and for simplicity it should probably continue to 
follow that. Calling it explicitly removes the assumption it 
requires an Lvalue. If it's const then calling it could be safe 
as the object/temporary/Rvalue never changes. Hard to say.

> 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.