Re: Destructors, const structs, and opEquals

[Andrei Alexandrescu]

On 12/13/10 9:28 AM, Don wrote:
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.

I agree we should ideally do better than that. The problem with the 
compiler taking initiative in the ref vs. value decision is undue aliasing:

void fun(const Widget a, Widget b) { ... }

In the call fun(x, x) the compiler may or may not alias a with b - a 
very difficult to detect bug. The two objects don't have to be 
parameters - one could be e.g. a global.

Andrei