On 2013/4/4 Eric Sampson wrote:
On Thursday, April 4, 2013 8:56:32 AM UTC-5, James Bardin wrote:
There's nothing special about the returned error. It doesn't have to be
the second argument, nor does it need to be the last (you can return more
than two things).
James, aside from enabling the cleaner syntax of the second case, the point
of the proposal is that it *makes* something special about the returned
error. By visually separating out returned errors from returned values, it's
immediately obvious to someone reading other people's code which of the
returns are values vs errors.
What's the point of that? Some people might want pointer variables to
be coloured in pink and interface variables to be coloured in green to
make it totally obvious... but for what purpose? Same thing here.
Right now there is total flexibility - you can
return errors anywhere in the return arguments and give them any name. When
you're scanning Go code, aside from looking up the function declaration, the
only thing telling you which return(s) is the error is the loose convention
of naming them something like 'err' and the fact that they are immediately
compared to nil.
Errors are not always compared to nil. There's little point in
returning errors if the only thing you do is comparing them to nil.
Why do you need "something telling you which is the error"? What does
Being called is enough to single out errors. If an error is not called
err, either the author wants to indicate something particular
(precisely singling out this variable), or has bad programming style.
Using weird punctuation symbols (and using punctuation symbols at all,
actually) brings more visual pollution than it singles things out.
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
For more options, visit https://groups.google.com/groups/opt_out.