grauzone wrote:
Robert Jacques wrote:
On Tue, 22 Sep 2009 12:32:25 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Daniel Keep wrote:
[snip]
The problem is that currently you have a class of types which can be
passed as arguments but cannot be returned.
For example, Tango's Variant has this horrible hack where the ACTUAL
definition of Variant.get is:
returnT!(S) get(S)();
where you have:
template returnT(T)
{
static if( isStaticArrayType!(T) )
alias typeof(T.dup) returnT;
else
alias T returnT;
}
I can't recall the number of times this stupid hole in the language
has
bitten me. As for safety concerns, it's really no different to
allowing
people to return delegates. Not a very good reason, but I *REALLY*
hate
having to special-case static arrays.
Yah, same in std.variant. I think there it's called
DecayStaticToDynamicArray!T. Has someone added the correct handling
of static arrays to bugzilla? Walter wants to implement it, but we
want to make sure it's not forgotten.
Well, what is the correct handling? Struct style RVO or delegate
auto-magical heap allocation? Something else?
Both solutions are far from perfect.
RVO breaks the reference semantics of arrays, though it works for many
common cases and is high performance. This would be my choice, as I
would like to efficiently return short vectors from functions.
Delegate style heap allocation runs into the whole
I'd-rather-be-safe-than-sorry issue of excessive heap allocations. I'd
imagine this would be better for generic code, since it would always
work.
I think static arrays should be value types. Then this isn't a problem
anymore, and returning a static array can be handled exactly like
returning structs.
Didn't Walter once say that a type shouldn't behave differently, if it's
wrapped into a struct? With current static array semantics, this rule is
violated. If a static array has reference or value semantics kind of
depends, if it's inside a struct: if you copy a struct, the embedded
static array obviously looses its reference semantics.
Yah.
Also, I second that it should be possible to declare void variables.
It'd be really useful for doing return value handling when transparently
wrapping delegate calls in generic code.
I think that already works.
Andrei
