[go-nuts] Go 2.0 feature request: disallow implicitly ignoring return values

On Sat, Aug 22, 2015 at 8:11 PM, wrote:

If I have a myStruct.MyMethod that returns something, currently it's
possible to just write:

myStruct.MyMethod()

and the compiler doesn't complain, silently ignoring the discarded return
value. This can lead to bugs if for instance MyMethod is in a library and
the user for some reason doesn't realise that it returns something.

My proposal is for the compiler to complain, requiring the programmer to
write

_ = myStruct.MyMethod()

if they wish to ignore the return value. This eliminates the possibility
of the programmer not realising that a method returns something, and makes
code review easier as it's clear where a return value/error is being
ignored.

--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.

On 22 August 2015 at 16:29, Micky wrote:
Someone wiser than me, once said:
"The core language is complete!"

So sorry, too late!

--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.

The OP said for G2.0, not a change to Go 1.*.

On the other hand, rather than having to fiddle with the language,
a vet plugin would seem to be the natural solution.

Chris


--
Chris "allusive" Dollin

--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.

On Sunday, 23 August 2015 02:01:51 UTC+10, Chris Kastorff wrote:

Someone already wrote this, specialized for check for ignoring "error"
type return types: https://github.com/kisielk/errcheck

On Sat, Aug 22, 2015 at 8:42 AM, 'chris dollin' via golang-nuts
<[email protected] <javascript:>> wrote:
wrote:
wrote:
return
and
to
possibility
makes
Groups
an
Groups
an

On Sunday, August 23, 2015 at 7:35:53 AM UTC+2, [email protected] wrote:

That's great, thanks! Is there a list somewhere of all the Go vet plugins
that people have created?

On Sat, Aug 22, 2015 at 8:11 AM, wrote:
If I have a myStruct.MyMethod that returns something, currently it's
possible to just write:

myStruct.MyMethod()

and the compiler doesn't complain, silently ignoring the discarded return
value. This can lead to bugs if for instance MyMethod is in a library and
the user for some reason doesn't realise that it returns something.

My proposal is for the compiler to complain, requiring the programmer to
write

_ = myStruct.MyMethod()

if they wish to ignore the return value. This eliminates the possibility of
the programmer not realising that a method returns something, and makes code
review easier as it's clear where a return value/error is being ignored.

On Saturday, 22 August 2015 16:30:32 UTC+1, Ian Lance Taylor wrote:
On Sat, Aug 22, 2015 at 8:11 AM, <[email protected] <javascript:>>
wrote:
This has been suggested before. In practice it seems to be too
invasive. For example, the fmt.Fprint functions return an error, as
they should. But if you fmt.Fprint to a bytes.Buffer or a
bufio.NewWriter, there is no reason at all to check the error for each
call to fmt.Fprint. So if we adopt your suggestion, the language is
forcing you to write extra text for a case that you can not happen.
That doesn't seem to be in the spirit of Go.

Perhaps there is some way to address this issue, but I don't think
this is the way.

Ian

On Saturday, August 22, 2015 at 9:30:32 AM UTC-6, Ian Lance Taylor wrote:
On Sat, Aug 22, 2015 at 8:11 AM, <[email protected] <javascript:>>
wrote:
This has been suggested before. In practice it seems to be too
invasive.

On Monday, August 24, 2015 at 9:02:02 PM UTC+2, Roger Pack wrote:


Agree.

However, something else (somewhat unrelated) is that this is disallowed:

err := someFunc();


but the following is allowed:

err := someFunc();
err := someOtherFunc();

if err != nil {

...


you can see that the first error is *ignored* but the compiler doesn't catch it.

Cheers!

On Monday, August 24, 2015 at 2:07:30 PM UTC-6, Val wrote:
Hi Roger
although I agree that shadowing can be tricky, your example is refused by
the compiler
with this code <http://play.golang.org/p/KZ3gI1rA76>
with this code too <http://play.golang.org/p/CHz_vUTCls>

The compiler is silent with this other code
<http://play.golang.org/p/H7jAnJoHra>, but here the new variable
declaration is almost obvious.

This code on go-traps <http://go-traps.appspot.com/#watchman-2> is more
tricky but also but complex.

Cheers
Val

If I have a myStruct.MyMethod that returns something, currently it's
possible to just write:

myStruct.MyMethod()

and the compiler doesn't complain, silently ignoring the discarded return
value. This can lead to bugs if for instance MyMethod is in a library and
the user for some reason doesn't realise that it returns something.

My proposal is for the compiler to complain, requiring the programmer to
write

_ = myStruct.MyMethod()

if they wish to ignore the return value. This eliminates the possibility
of the programmer not realising that a method returns something, and makes
code review easier as it's clear where a return value/error is being
ignored.

On Sat, 2015-08-22 at 08:11, [email protected] wrote:
If I have a myStruct.MyMethod that returns something, currently it's
possible to just write:

myStruct.MyMethod()

and the compiler doesn't complain, silently ignoring the discarded return
value. This can lead to bugs if for instance MyMethod is in a library and
the user for some reason doesn't realise that it returns something.

My proposal is for the compiler to complain, requiring the programmer to
write

_ = myStruct.MyMethod()

if they wish to ignore the return value. This eliminates the possibility of
the programmer not realising that a method returns something, and makes
code review easier as it's clear where a return value/error is being
ignored.

On Saturday, 22 August 2015 16:11:18 UTC+1, [email protected] wrote:

If I have a myStruct.MyMethod that returns something, currently it's
possible to just write:

myStruct.MyMethod()

and the compiler doesn't complain, silently ignoring the discarded return
value. This can lead to bugs if for instance MyMethod is in a library and
the user for some reason doesn't realise that it returns something.

My proposal is for the compiler to complain, requiring the programmer to
write

_ = myStruct.MyMethod()

if they wish to ignore the return value. This eliminates the possibility
of the programmer not realising that a method returns something, and makes
code review easier as it's clear where a return value/error is being
ignored.