Destructors, const structs, and opEquals

[spir]

On Sat, 11 Dec 2010 09:06:33 -0500
Michel Fortin <michel.fortin at michelf.com> wrote:

> 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.
 
If parameters are 'in' or 'const' by default, then whether they are passed by value or by ref has no consequence, I guess. The compiler can then safely choose the most efficent more --what it can do as it knows sizeof-- grossly structs by ref, the rest by value. Is this reasoning correct?


Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com