One document about Go

[Lurker]

== Quote from bearophile (bearophileHUGS at lycos.com)'s article
> Lurker:
> Combine the 2 things into one struct and return by value. Multi-value
return makes for hard to comprehend code. So, IMO, it's hardly syntactic
sugar: it's syntactic grafitti.

"You are very wrong, multiple return values are good, if they have a good
enough syntax."

Maybe. Or maybe just your personal opinion/preference. Your first example
looked ugly to me, but I'll see what you did further here and "decide" for
myself if I'd go that far with the "standard C syntax". It does seem like a
complete rethinking of the whole function call syntax and behavior and the
multiple return concept is just one of many if someone was going to start
with a clean slate. Another person may argue that only error codes should be
returned from functions and everything else gets passed as arguments: no
return values, basically then. Since I'm thinking aloud, I will say that I
think the issue in isolation probably can't be effectively dealt with. At
least I would approach it from a higher level to see where the suggestion
fits-in in the grand scheme of things.

"Regarding this C/C++/D/Java/C#/etc are worse and Python and Go are better.
Multiple return values make code simpler to write, simpler to read and
remove the need for silly and logically ridiculous features like "out"
arguments (an input value that is a return? This is making things go
backwards)."

Or so it would seem "backwards" if you decide to view what's in-between the
parens to a called function as "in" args. Which of course they are not, by
design. In C, from where much of existing syntax is derived, "reference
args" are not hard to grasp.

"D language isn't even able to tell if an "out" argument has being used
before it is assigned inside the function (as C# compiler is able to,
because in C# using uninitialized variables is an error) This is awful and
surely worse than multiple return values."

The closest I have come to "in" or "out" keywords has been reading of
MS "managed code" documentation, so I can't see the value in that nor
multiple return values (yet?). I'll probably learn more by lurking in this
thread, so don't waste too much of your time responding to me if I'm
not "getting it".

> import std.stdio: writeln;
> import std.conv: to;
> int foo(int x, out string s) {
>     writeln(s);
>     int result = x * x;
>     s = to!string(result);
>     return result;
> }
> void main () {
>     string s;
>     writeln(s);
>     int r = foo(10, s);
>     writeln(r);
> }

> A possible syntax for D multiple return values:
> import std.stdio: writeln;
> import std.conv: to;
> (int, string) foo(int x) {
>     int result = x * x;
>     return (result, to!string(result));
> }
> void main () {
>     (int r, string s) = foo(10);
>     writeln(s);
>     writeln(r);
> }

Looks too foreign, and like it has too much ramification for parsing (not
that I'd know though). This kind of thing seems like something to work out
at language design time and not years after language introduction.

> The second is simpler to understand code and less bug-prone than the first.

That's a weak case at best. While D's "in" and "out" modifiers are surely to
help the compiler in some way mostly, I don't have any issue with the old
way of doing it. It seems more stylistic than anything else.

> An alternative syntax:
> import std.stdio: writeln;
> import std.conv: to;
> [int, string] foo(int x) {
>     int result = x * x;
>     return [result, to!string(result)];
> }
> void main () {
>     [int r, string s] = foo(10);
>     writeln(s);
>     writeln(r);
> }

I'm not a big fan of overloading parens and brackets yet another way. I
think conceptually, multiple return values may be another straw the tips the
scale toward D becoming unacceptably cryptic (it'a already very cryptic)
rather than useable, especially to those who have never programmed before.
Again though, this all sounds like first thoughts on a new programming
language rather than an existing one.

> ------------
> Walter Bright:
> > C got it right and it doesn't need fixing.
> I have never programmed in Go, but keep in mind that Go designers are
expert language designers and programmers. They aren't stupid people.
> Anyway, this is not so important. Named arguments and multiple return
values are quite more important (for D3).
> Bye,
> bearophile