FAQ
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 golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Micky at Aug 22, 2015 at 3:30 pm
    Someone wiser than me, once said:
    "The core language is complete!"

    So sorry, too late!
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Chris dollin at Aug 22, 2015 at 3:42 pm

    On 22 August 2015 at 16:29, Micky wrote:
    Someone wiser than me, once said:
    "The core language is complete!"
    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
    So sorry, too late!
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.


    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Chris Kastorff at Aug 22, 2015 at 4:01 pm
    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
    wrote:
    On 22 August 2015 at 16:29, Micky wrote:
    Someone wiser than me, once said:
    "The core language is complete!"
    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
    So sorry, too late!
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.


    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jonathan T Barnard at Aug 23, 2015 at 5:35 am
    That's great, thanks! Is there a list somewhere of all the Go vet plugins
    that people have created?
    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
    <golan...@googlegroups.com <javascript:>> wrote:
    On 22 August 2015 at 16:29, Micky <mickyl...@gmail.com <javascript:>>
    wrote:
    Someone wiser than me, once said:
    "The core language is complete!"
    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
    So sorry, too late!

    On Sat, Aug 22, 2015 at 8:11 PM, <jonathan....@gmail.com <javascript:>>
    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 golang-nuts...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.

    --
    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 golang-nuts...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.


    --
    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 golang-nuts...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Mateusz Czapliński at Aug 24, 2015 at 3:07 pm

    On Sunday, August 23, 2015 at 7:35:53 AM UTC+2, jonathan....@gmail.com wrote:

    That's great, thanks! Is there a list somewhere of all the Go vet plugins
    that people have created?
    gometalinter (https://github.com/alecthomas/gometalinter) has a fairly big
    list of various vet-like apps people have created - and as a bonus, helps
    to use them all in sane and manageable way.

    /M.

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at Aug 22, 2015 at 3:30 pm

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

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Xiiophen at Aug 22, 2015 at 5:53 pm

    On Saturday, 22 August 2015 16:30:32 UTC+1, Ian Lance Taylor wrote:
    On Sat, Aug 22, 2015 at 8:11 AM, <jonathan....@gmail.com <javascript:>>
    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.
    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
    I had a self inflicted bug from this not long ago.. I thought that compiler
    warnings might be useful here when return values are skipped (exclude core
    packages?)

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Roger Pack at Aug 24, 2015 at 7:02 pm

    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, <jonathan....@gmail.com <javascript:>>
    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.
    This has been suggested before. In practice it seems to be too
    invasive.
    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!

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Val at Aug 24, 2015 at 8:07 pm
    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
    On Monday, August 24, 2015 at 9:02:02 PM UTC+2, Roger Pack wrote:


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

    This has been suggested before. In practice it seems to be too
    invasive.
    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!
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Roger Pack at Aug 25, 2015 at 7:07 pm

    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>
    Oops I was referring to this, sorry for not checking it first (the first
    returned err is assigned, never used, and happily accepted by the compiler):

    http://play.golang.org/p/eupSA3Q6_Q




    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
    On Monday, August 24, 2015 at 9:02:02 PM UTC+2, Roger Pack wrote:


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

    This has been suggested before. In practice it seems to be too
    invasive.
    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!
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Rogerjd at Aug 22, 2015 at 9:48 pm
    As soon as that feature is added, a request will be made to remove it. (It
    is user responsibility to check what values are returned from a func, and
    code accordingly)
    Roger

    On Saturday, August 22, 2015 at 11:11:18 AM UTC-4, jonathan....@gmail.com
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Milan P. Stanic at Aug 22, 2015 at 10:56 pm

    On Sat, 2015-08-22 at 08:11, jonathan.t.barnard@gmail.com 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()
    I hope this proposal never will be accepted.

    myStruct.MyMethod() have legitimate use cases.
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Si Robertson at Aug 23, 2015 at 1:12 pm
    That change would break an enormous amount of existing code, including code
    in the standard Go packages. Don't forget Go only knows errors, it has no
    idea what warnings are unfortunately, and errors prevent code compilation
    from completing.

    Anyway, values returned from function calls can be ignored in most
    programming languages so I don't see why Go should be the hipster who
    pushes against that pseudo-standard behaviour :)

    On Saturday, 22 August 2015 16:11:18 UTC+1, jonathan....@gmail.com 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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedAug 22, '15 at 3:11p
activeAug 25, '15 at 7:07p
posts14
users12
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase