Dan Hursh <hursh@infonet.isl.net> writes:

> > (foo, bar) = func();

> It's also nicer when you want the returned data in certain variables ratherthan a struct.  Less copying than.
> 
> ret_t ret = func();
> foo = ret.f;
> bar = ret.b;

The problem with the first approach is the following: It is not clear if you have to write:

        (write_end, read_end) = Create_Pipe();

Or:

        (read_end, write_end) = Create_Pipe();

In general, I don't think it's a good idea to trade readability for
terseness.

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Florian Weimer wrote:
> 
> Dan Hursh <hursh@infonet.isl.net> writes:
> 
> > > (foo, bar) = func();
> 
> > It's also nicer when you want the returned data in certain variables ratherthan a struct.  Less copying than.
> >
> > ret_t ret = func();
> > foo = ret.f;
> > bar = ret.b;
> 
> The problem with the first approach is the following: It is not clear if you have to write:
> 
>         (write_end, read_end) = Create_Pipe();
> 
> Or:
> 
>         (read_end, write_end) = Create_Pipe();
> 
> In general, I don't think it's a good idea to trade readability for terseness.

	And it's clearer when it's:

		Create_Pipe(write_end, read_end);

	Or:

		Create_Pipe(read_end, write_end);

	I guess I'd really like the ability to choose between returning a list
of values to a set of variables, an array, or a struct with the correct
members.  They are all useful sometimes, but not of them feel right in
all cases.  This is mostly aesthetics though.  Weather it's function
return values though or function parameters you still have to know what
order they are.  (Unless we use named parameters.  That doesn't look
likely.)  At least with you two examples it would be easier to tell what
is input and what is output.  The function name just becomes a glorified
infix operator between a list of input values (on the right) and output
locations (on the left).
	Of course, as soon as you do this sort of syntax, someone will ask for
the ability to overload based on return list types.  Suddenly you would
have to keep track of calling context or some such thing.
	I would be nice, but against the D way of doing things.

Dan

Dan Hursh <hursh@infonet.isl.net> writes:

> > In general, I don't think it's a good idea to trade readability for terseness.
> 
> 	And it's clearer when it's:
> 
> 		Create_Pipe(write_end, read_end);
> 
> 	Or:
> 
> 		Create_Pipe(read_end, write_end);

Some people prefer:

        Create_Pipe (Write_End => Write_End_Var,
                     Read_End  => Read_End_Var);

(Named parameter associations, 'Write_End' is the name of the formal
parameter in the declaration of 'Create_Pipe'). ;-)

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

The DM compiler doesn't do extra copies.

Christophe de Dinechin wrote in message <3B841E54.D4D364A9@earthlink.net>...
>It's not ugly, but it's infrequent enough that most compilers generate inefficient code for that. Hence people don't use it. Catch 22.
>
>Typically, you get a lot of extra copies while returning a struct (at least one, sometimes 2). LX tries to solve that with the "result" pseudo-variable.
>
>Christophe
>
>Russell Bornschlegel wrote:
>
>> Richard Krehbiel wrote:
>> >
>> > "Russell Bornschlegel" <kaleja@estarcion.com> wrote in message news:3B81DC85.7321FD3E@estarcion.com...
>> > >   // hmm, can you access a member of the result of a function call?
>> > >   if (!read( filedesc, buffer, size ).success)
>> > >   {
>> > >      printf("read failed, sucks to be you...\n" );
>> > >   }
>> >
>> > I just tested this, and it compiled and worked. [snip example]
>>
>> In C, no less! Will wonders never cease. (What compiler was that,
>> by the way?)
>>
>> So, I repeat the question: is returning a struct from a commonly used library routine such an ugly construct that we need to come up with a better way to handle the return of multiple values from a function?
>>
>> -RB
>