multiple return values (new syntax proposal)

[aleksandar.ristovski]

Hello all,

I have been thinking about a possible extension to C/C++ syntax.

The current syntax allows declaring a function that returns a value:

int foo();

however, if I were to return more than one value, for example three
int-s, I would have to change my "logic" and pass the references to my
return values (i.e. declare them in the argument list) or to declare an
extra-struct representing the return type of three ints (extra work and
extra types). The function would look something like:

int foo(int&,int&);
or
void foo(int &, int&, int&);
or
struct rettype
{
int a, b, c;
};

rettype foo();

Would it not be nice if I could keep the thinking "return values are on
the left-hand side" and do something like this:

----
declaration:

{int, int, int} foo();
----
definition:

{int, int, int} foo()
{
...
return {1, 42, 0};
}
----
code:

int a, b, c;
{a, b, c} = foo();
----
I picked the curly braces, but it could be something else, it doesn't
matter - I am talking about the principle.

What do you think?

[Victor Bazarov]

al******************@gmail.com wrote:

I have been thinking about a possible extension to C/C++ syntax.

[..]
int a, b, c;
{a, b, c} = foo();
----
I picked the curly braces, but it could be something else, it doesn't
matter - I am talking about the principle.

What do you think?

What problem does it solve that cannot be solved by returning a struct?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[aleksandar.ristovski]

It is not solving any particular problem that can not be solved with
current syntax. It just, in my opinion, makes the way of thinking about
returned values more consistent: they are on the left-hand side of the
function decl.

I would, of course, not replace passing by ref or other methods, just
add this one. It would make already beautiful language even more
beautiful :-)

[Thomas J. Gritzan]

al******************@gmail.com schrieb:

I have been thinking about a possible extension to C/C++ syntax.

The current syntax allows declaring a function that returns a value:

int foo();

however, if I were to return more than one value, for example three
int-s, I would have to change my "logic" and pass the references to my
return values (i.e. declare them in the argument list) or to declare an
extra-struct representing the return type of three ints (extra work and
extra types).

The extra struct could be a nice template, like std::pair or boost::tuple:

http://www.boost.org/libs/tuple/doc/...ers_guide.html

With boost::tie, you can even unpack the pair or tuple into single variables.

--
Thomas
http://www.netmeister.org/news/learn2quote.html

[Kaz Kylheku]

al******************@gmail.com wrote:

Hello all,

I have been thinking about a possible extension to C/C++ syntax.

The current syntax allows declaring a function that returns a value:

int foo();

however, if I were to return more than one value, for example three
int-s, I would have to change my "logic" and pass the references to my
return values (i.e. declare them in the argument list) or to declare an
extra-struct representing the return type of three ints (extra work and
extra types). The function would look something like:

int foo(int&,int&);
or
void foo(int &, int&, int&);
or
struct rettype
{
int a, b, c;
};

rettype foo();

Would it not be nice if I could keep the thinking "return values are on
the left-hand side" and do something like this:

----
declaration:

{int, int, int} foo();
----
definition:

{int, int, int} foo()
{
...
return {1, 42, 0};
}
----
code:

int a, b, c;
{a, b, c} = foo();
----
I picked the curly braces, but it could be something else, it doesn't
matter - I am talking about the principle.

What do you think?

I think that you should also have the possibility that the function
need not supply all of the return values. In that case, the return
values have to have default initializers;

{int, int = 42} foo() { return 3; } // returns 3, 42

The callers should not be required to capture all of the return values.
Presently, you can call a function and ignore the result. Multiple
return values would preserve this freedom:

foo(); // 3, 42 thrown away

int x = foo(); // x = 3

{ x } = foo(); // x = 3

It might be worthwhile to look at Common Lisp multiple values.

Here is a possible alternative syntax:

// group together destinations for multiple values
// mnemonic: "into"

>{ lvalue ... }

// capture multiple values emanating from expression
// mnemonic: "extract"
<{ expr }

The >{ and <{ could be recognized as tokens, which gets rid of
ambiguities against compound statements.

This would allow for these uses:

// foo takes three arguments
// bar yields three values
// here, bar's three values become arguments for foo:
// analogous to Common Lisp multiple-value-call.
foo(<{bar()});

// here quux is a one argument function
// it takes only the first return value of bar
quux(bar());

// assignment of four values to four lvalues

>{x, y, z.field, *p} = <{returns_four_values()};

The >{ } could be permitted to enclose a declaration, allowing for the
binding of a group of variables to multiple values:

>{ unsigned int x, y; double z = 42 } = <{ func(arg); }

Here, z gets 42 if the function returns only three values, otherwise it
takes the fourth value.

[Noah Roberts]

al******************@gmail.com wrote:

declaration:

{int, int, int} foo();

How about:

std::tr1::tuple<int, int, intfoo();

[aleksandar.ristovski]

I was not trying to find a way to return more than one value (my
"struct" example is functionally equivalent to using tuple template).
My idea was to increase the clarity of the written code.

Additionally, the "extension to the syntax" I talked about would be
applicable to C as well.

Noah Roberts wrote:

al******************@gmail.com wrote:

declaration:

{int, int, int} foo();

How about:

std::tr1::tuple<int, int, intfoo();

[Kai-Uwe Bux]

al******************@gmail.com wrote:

Hello all,

I have been thinking about a possible extension to C/C++ syntax.

The current syntax allows declaring a function that returns a value:

int foo();

however, if I were to return more than one value, for example three
int-s, I would have to change my "logic" and pass the references to my
return values (i.e. declare them in the argument list) or to declare an
extra-struct representing the return type of three ints (extra work and
extra types). The function would look something like:

int foo(int&,int&);
or
void foo(int &, int&, int&);
or
struct rettype
{
int a, b, c;
};

rettype foo();

Would it not be nice if I could keep the thinking "return values are on
the left-hand side" and do something like this:

----
declaration:

{int, int, int} foo();
----
definition:

{int, int, int} foo()
{
...
return {1, 42, 0};
}
----
code:

int a, b, c;
{a, b, c} = foo();

What would be the meaning of

{ ignored, b, ignored } = foo();

Is that supposed to yield undefined behavior? If so, I would need to have
n-1 dummy variables if I want to ignore all but one returned value.

Also, where in the type system do you put these triples? I.e., if I have

template < typename T >
void bar ( T const & t ) {
...
}

and do

bar ( foo() );

what is the type T that will be chosen? If it is some tuple-type, would the
proposed meaning of

{ a, b, c } = foo();

really be consistent with our expectations? I would read that as:

create a tripple temporary from the values a, b, c
assign foo() to that temporary overwriting the old values
throw the temporary away

The meaning of {1,42,0} in your return statement seems to be exactly that:
form a temporary triple from 1, 42, and 0; then return the temporary.

>

----
I picked the curly braces, but it could be something else, it doesn't
matter - I am talking about the principle.

What do you think?

I think your proposal does not interact nicely with the type system of C++.
Best

Kai-Uwe Bux

[Julián Albo]

al******************@gmail.com wrote:

I was not trying to find a way to return more than one value (my
"struct" example is functionally equivalent to using tuple template).
My idea was to increase the clarity of the written code.

This type of constructions will be very difficult to implement in C++
without a big redesign of the language. And in order to have any hope to be
evaluated by the standard commitee, you must do a lot of work to
demonstrate that can be done without interfering with any existing syntax
or semantic (preferably by providing a working implementation). I suggest
you to read "The design and implementation of C++", It has a good
explanation of the process of proposing and accepting extensions.

--
Salu2