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.
