Destructors, const structs, and opEquals

[Michel Fortin]

On 2010-12-10 19:32:30 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

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

If I understand you well Andrei, what you want "auto ref" to be the 
same thing as "ref" except that it would also accept rvalues. I think 
the reason you want this is because for some types it is more efficient 
to pass them as "ref" than by value, so you want to pass them as "ref" 
for efficiency and and not necessarily for its semantics. And from 
there goes the need for a "ref" that also accepts rvalues.

I think this is a bad usage of "ref". Efficient should be the way 
arguments are passed by default, and modifiers should be used to alter 
semantics and not required for efficiency (in most situations). Is 
there a way to pass arguments more efficiently without introducing a 
bazillion options the programmer then has to choose from?

Perhaps we're just trying to address the problem from the wrong end. 
Instead of having to say for each function parameter how you want it to 
be passed, what if the type itself knew how it should be passed as a 
parameter?

	@passbyref struct ArrayOf50 {
		float[50] content;
	}

	string test1(ArrayOf50 a);     // accepts rvalues
	string test2(ref ArrayOf50 a); // rejects rvalues

	void main() {
		test1(ArrayOf50());
		test2(ArrayOf50()); // error, first argument requires a reference
	}

Now, obviously we've given different semantics to the type itself, but 
those semantics are going to be consistent and predictable everywhere. 
But mostly, you don't have to remember how to pass this struct every 
time now. That's a really big gain.

Also note how you could use this feature to design containers which 
don't need to be reference counted but which are still passed 
efficiently across function calls.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/