Yet another MRV proposal!

[Bill Baxter]

Simen Kjaeraas wrote:
> On Mon, 14 Apr 2008 11:23:50 +0200, downs <default_357-line at yahoo.de> 
> wrote:
> 
>> Let's give this another try.
>> The following proposal has the advantage that it's funded mostly on 
>> existing syntax.
>>
>> An anonymous struct, in the position where you'd normally expect a 
>> function/method return type, is usable as the return type instead.
>>
>> Example:
>>
>> struct { int a; float b; } test() { return(1, 2f); }
>>
>> writefln(test().a, test().b);
>>
>> The compiler would translate this into "current D" as follows:
>>
>> struct _D_anonymous_struct_1 { int a; float b; }
>> _D_anonymous_struct_1 test() { return _D_anonymous_struct_1(1, 2f); }
>>
>> Because of the not-exactly-clear type name, it is necessary to store 
>> the returned value in an auto/const/static variable.
>>
>> This looks like it could be ambiguous, but it really isn't - the two 
>> conditions required here - an unnamed struct in the position where a 
>> return type would be expected - are quite unambiguous :)
>>
>> Whaddya think?
>>
>>  --downs
> 
> 
> Looks pretty good - there are reasons to allow returning anonymous
> structs, and I'm sure they could find uses in other places as well.
> 
> One problem I see is that, compared to 'true' MRV, it requires extra
> assignments if you want the values outside the struct.
> 

Hmm, yeh, I didn't take the proposal to be a replacement for other more 
Tuple-ish MRV discussions.  It only makes sense to use structs if you 
care about given names to the elements.  If you don't care about having 
named elements, like

    a,b = get_minmax();

then a tuple-based solution makes more sense.
That's why I was asking if he actually needed that.  I meant did he 
really need multiple return values where the values were named, and not 
anonymous like in a Tuple.


--bb