"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.

typedef struct multi
{
    int a, b, c;
} M;

M sub(void)
{
    M a;
    a.a = 1;
    a.b = 2;
    a.c = 3;
    return a;
}

int main(int argc, char *argv[])
{
    M res;

    if((res = sub()).a == 1)
        printf("OK, %d, %d, %d\n", res.a, res.b, res.c);

    return 0;
}

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

Brent Schartung wrote:
> Just use contracts; that's what they're there for.  The contract will
> specify that the returned array should have three elements, and the code will (!)be commented to describe the returned contents.  Keep it simple!

Contracts would handle it, but an exception might be easier to recover from.  Also, if one is going to assign the return value of a function to an array, it might be just as well if one could be sure that it wouldn't overfill the array.

Ships  docked[5];     --  only room to tie up 5 ships
try 

{  docked = pilot_log(today);
   ...
}
catch trafficJam (msg)
{   ...
}

Angus Graham wrote:
> ...
> What am I missing here?
> 
> Angus Graham
> 
It's not difficult.  It's not obscure.  It's not uncommon.

But is it useful?

In D there are in/out parameters to functions.

It's useful for a function to return one value, so that it can be processed in a stream of arithmetic or inheritance.  For multiple values?  They would seem to clog up this process unless tuples are a part of the language.  Use an array return value instead.

"Charles Hixson" <charleshixsn@earthlink.net> wrote

> Angus Graham wrote:
> > ...
> > What am I missing here?
> >
> > Angus Graham
> >
> It's not difficult.  It's not obscure.  It's not uncommon.
>
> But is it useful?

Not less useful than i/o parameters

> In D there are in/out parameters to functions.

Which suffer from the problem stated above - you can't tell from looking at a call which is which.  I suggest not having both, but replacing i/o params with this system.

> It's useful for a function to return one value, so that it can be processed in a stream of arithmetic or inheritance.  For multiple values?  They would seem to clog up this process unless tuples are a part of the language.  Use an array return value instead.

I wouldn't be in favour of tuples, but you could still use one of the
multiple return values in arithmetic operations:
In c, the ',' operator evaluates its args left to right and takes on the
value of the right operand. Multiple arguments returned from functions would
be "comma'd" just as if you had written them out with the regular comma
operator. Thus:

ERROR e;
int items;
items = (e, items = row->get_items()) + 1;

would add 1 to the int returned by row->get_items() and retrieve an error as
a bonus.

items = row->get_items() + 1;

would do the same thing, except the error would be put a temporary, not assigned anywhere and lost.

You could pass the result to a function that takes only one argument:

row->set_items(row->get_items() + 1);




Angus Graham

"Russell Bornschlegel" <kaleja@estarcion.com> wrote in message news:3B82917B.FB34BD40@estarcion.com...
>
>
> 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?
>

You cannot guarantee that all fields of a struct are populated.

You have to have different structs for different kinds of functions, making the number of types you have to learn to use system functions much larger (plus this multiplies per user function which has a different struct return type)

And YES it is *UGLY* =)

Peter.

kaffiene wrote:
> 
> "Russell Bornschlegel" <kaleja@estarcion.com> wrote in message news:3B82917B.FB34BD40@estarcion.com...
> > 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?
> >
> 
> You cannot guarantee that all fields of a struct are populated.

Give it a constructor.

> You have to have different structs for different kinds of functions, making the number of types you have to learn to use system functions much larger (plus this multiplies per user function which has a different struct return type)

This point is granted; you can define your APIs in such a way that the number of return-struct types is minimized, however.

> And YES it is *UGLY* =)

Well, I'm not thrilled with:

   numCats,numDogs,numFerrets,numGoats = CountAnimals();

...either. I think the parser would want at least some sort of marker around the return list, also, something like:

  [numCats, numDogs, numFerrets, numGoats] = CountAnimals();
  {numCats, numDogs, numFerrets, numGoats} = CountAnimals();
  (numCats, numDogs, numFerrets, numGoats) = CountAnimals();
  <numCats, numDogs, numFerrets, numGoats> = CountAnimals();
  [numCats, numDogs, numFerrets, numGoats] = CountAnimals();
  `numCats, numDogs, numFerrets, numGoats` = CountAnimals();
  \numCats, numDogs, numFerrets, numGoats\ = CountAnimals();

Eeech.

-RB

Im Artikel <3B82E1F6.851406A@estarcion.com> schrieb "Russell Bornschlegel" <kaleja@estarcion.com>:

> kaffiene wrote:
>> 
>> "Russell Bornschlegel" <kaleja@estarcion.com> wrote in message news:3B82917B.FB34BD40@estarcion.com...
>> > 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?
>> >
>> >
>> You cannot guarantee that all fields of a struct are populated.
> 
> Give it a constructor.
> 
>> You have to have different structs for different kinds of functions, making the number of types you have to learn to use system functions much larger (plus this multiplies per user function which has a different struct return type)
> 
> This point is granted; you can define your APIs in such a way that the number of return-struct types is minimized, however.
> 
>> And YES it is *UGLY* =)
> 
> Well, I'm not thrilled with:
> 
>    numCats,numDogs,numFerrets,numGoats = CountAnimals();
> 
> ...either. I think the parser would want at least some sort of marker around the return list, also, something like:
> 
>   [numCats, numDogs, numFerrets, numGoats] = CountAnimals();
>   {numCats, numDogs, numFerrets, numGoats} = CountAnimals();
>   (numCats, numDogs, numFerrets, numGoats) = CountAnimals();
>   <numCats, numDogs, numFerrets, numGoats> = CountAnimals();
>   [numCats, numDogs, numFerrets, numGoats] = CountAnimals();
>   `numCats, numDogs, numFerrets, numGoats` = CountAnimals();
>   \numCats, numDogs, numFerrets, numGoats\ = CountAnimals();
> 
> Eeech.

I dunno. In the following:

(cats, dogs, ferrets, goats) = CountAnimals(zoo, pound, farm, petshop);

Why is the parenthesis-bounded list of returned variables uglier than the parenthesis-bounded list of function arguments?

-- 
Sheldon Simms / sheldon@semanticedge.com

Russell Bornschlegel wrote:

> kaffiene wrote:
> >
> > "Russell Bornschlegel" <kaleja@estarcion.com> wrote in message news:3B82917B.FB34BD40@estarcion.com...
> > > 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?
> > >
> >
> > You cannot guarantee that all fields of a struct are populated.
>
> Give it a constructor.

Remember that in D structs are NOT classes, so they don't have constructors or other member functions.  You can define default initializers for all of the members, though.

"Russell Bornschlegel" <kaleja@estarcion.com> wrote in message news:3B82E1F6.851406A@estarcion.com...
>
>
> kaffiene wrote:
> >
> > "Russell Bornschlegel" <kaleja@estarcion.com> wrote in message news:3B82917B.FB34BD40@estarcion.com...
> > > 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?
> > >
> >
> > You cannot guarantee that all fields of a struct are populated.
>
> Give it a constructor.

You can guarantee the struct has initialisers (or constructors if D had them for structs) on user functions.  The compiler can guarantee a binding for returned values from *all* functions.

> > You have to have different structs for different kinds of functions,
making
> > the number of types you have to learn to use system functions much
larger
> > (plus this multiplies per user function which has a different struct
return
> > type)
>
> This point is granted; you can define your APIs in such a way that the number of return-struct types is minimized, however.
>
> > And YES it is *UGLY* =)
>
> Well, I'm not thrilled with:
>
>    numCats,numDogs,numFerrets,numGoats = CountAnimals();
>
> ...either. I think the parser would want at least some sort of marker around the return list, also, something like:
>
>   [numCats, numDogs, numFerrets, numGoats] = CountAnimals();
>   {numCats, numDogs, numFerrets, numGoats} = CountAnimals();
>   (numCats, numDogs, numFerrets, numGoats) = CountAnimals();
>   <numCats, numDogs, numFerrets, numGoats> = CountAnimals();
>   [numCats, numDogs, numFerrets, numGoats] = CountAnimals();
>   `numCats, numDogs, numFerrets, numGoats` = CountAnimals();
>   \numCats, numDogs, numFerrets, numGoats\ = CountAnimals();

No - a compiler can do:

    a,b = myfunc(x);

No problem at all - there is no reason you have have markers around the return list.

Peter.