Destructors, const structs, and opEquals

[Don]

Andrei Alexandrescu wrote:
> On 12/10/10 4:10 PM, foobar wrote:
>> Don Wrote:
>>
>>> Steven Schveighoffer wrote:
>>>> To summarize for those looking for the C++ behavior, the equivalent
>>>> would be:
>>>>
>>>> void foo(auto ref const Widget)
>>>
>>> That use of 'auto' is an abomination.
>>
>> I agree with don.
>> IMHO, this is incredibly silly given Andrei's use case, since D can 
>> have instead:
>> void foo(const Widget);
>> and have an optimization inside the compiler for value types to pass 
>> by ref.
> 
> Everyone - please stop suggesting that. It causes severe undue aliasing 
> issues.
> 
> Andrei

I don't understand this.

For sure,
const Widget foo(const Widget  x) { return x; }

is inefficient.

But I don't see how problems can ever arise with a function which 
returns a built-in type (eg, opEquals() ).

It seems to me, that the issue relates to deterministic destruction.

As I see it, there can be two forms of const parameters:
* caller manages lifetime. Caller must call destructor. It must 
duplicate anything it wants to return.
* callee manages lifetime. Callee must destroy the variable, or return it.

Interestingly, any parameter marked as 'inout' is the second form.
Seems pretty clear to me that opEquals needs the first form.
And I think it's a pretty common case: I'm only going to look at this 
variable, I'm not going to take ownership of it or modify it any way.

We have
ref const in inout scope 'auto ref' (which does not mean auto + ref).

And yet, even with this zoo of modifiers, the best syntax we have for 
that simple situation is 'auto ref const' ???

We've got to do better than that.