Yet another MRV proposal!

Hans W. Uhlig huhlig at gmail.com
Fri Apr 18 13:10:07 PDT 2008


Bill Baxter wrote:
> downs 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
> 
> It does seem reasonable that you should be able to return an anonymous 
> struct (or class).
> 
> I guess for a no-element struct you could use "return (); "?
> Or for an anon struct with default values.
> 
> struct{int a=1; int b=2;} foo() { return(); }
> 
> The return becomes like an invocation of static opCall, except you leave 
> the name of the struct off, because it's anonymous.
> 
> For classes syntax could be like
> 
> class{int a=1; int b=2;} foo() { return new (); }
> 
> Do you have a need for this?
> 
> --bb
I agree with this an it was part of what I was hashing out with the 
alternate declaration syntax. Having Multiple return values in a const 
environment seems to me to lead to an easier transition to parallel 
processing in an imperative environment. Technically yes, you can 
manually generate a struct for each function needing to return multiple 
values back. Multiple const/invariant in and one out seems to me at 
least to be a flaw in design. Since once the input date is frozen and 
passed in, it becomes immutable and then gets duped inside the function 
and dealt with. A simple method for returning multiple non const values 
back out(to be reintegrated with the larger DS, filed or whatnot) would 
be very useful.

However as Scott has shown me I do not necessarily understand the 
implementations of these ideas, only the academic principles.



More information about the Digitalmars-d mailing list