FAQ
I was surprised recently when I found a bug in my program that I would have
expected to be caught by the compiler or "go vet".

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

It appears that even if your function declares a return type, it will
compile without a proper return of that type so long as there is an
infinite loop.

The behavior is documented here:

http://golang.org/doc/go1.1#return

I suppose I expected that the compiler would have failed to compile my
program, or at least that "go vet" would have mentioned it since it seems
unlikely that I'd actually want to declare a function with a return type
but then implement the function in such a way as to never return any value
whatsoever. (if you do have a return statement after the for loop, "go vet"
will detect the unreachable code)

Thought I'd share and I'd love to hear other's thoughts on this behavior.



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

  • Martin Drlík at Apr 29, 2014 at 7:07 pm
    For me it's ok. It's forever so why you should put something after it. Put
    break to for and it fails to compile.
    On Tuesday, April 29, 2014 8:58:35 PM UTC+2, Freedom Dumlao wrote:

    I was surprised recently when I found a bug in my program that I would
    have expected to be caught by the compiler or "go vet".

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

    It appears that even if your function declares a return type, it will
    compile without a proper return of that type so long as there is an
    infinite loop.

    The behavior is documented here:

    http://golang.org/doc/go1.1#return

    I suppose I expected that the compiler would have failed to compile my
    program, or at least that "go vet" would have mentioned it since it seems
    unlikely that I'd actually want to declare a function with a return type
    but then implement the function in such a way as to never return any value
    whatsoever. (if you do have a return statement after the for loop, "go vet"
    will detect the unreachable code)

    Thought I'd share and I'd love to hear other's thoughts on this behavior.


    --
    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.
  • Minux at Apr 29, 2014 at 8:13 pm

    On Tue, Apr 29, 2014 at 2:58 PM, Freedom Dumlao wrote:

    I was surprised recently when I found a bug in my program that I would
    have expected to be caught by the compiler or "go vet".

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

    It appears that even if your function declares a return type, it will
    compile without a proper return of that type so long as there is an
    infinite loop.

    The behavior is documented here:

    http://golang.org/doc/go1.1#return

    I suppose I expected that the compiler would have failed to compile my
    program, or at least that "go vet" would have mentioned it since it seems
    unlikely that I'd actually want to declare a function with a return type
    but then implement the function in such a way as to never return any value
    whatsoever. (if you do have a return statement after the for loop, "go vet"
    will detect the unreachable code)

    Thought I'd share and I'd love to hear other's thoughts on this behavior.
    The program is perfectly valid, if there isn't a return statement present,
    how could the compiler
    check the type of the returned value.

    As soon as you add a way to break from the loop, the compiler will
    correctly complain that
    return statement is missing.

    It's not the compiler's job to stop you from writing this kind of programs,
    go vet probably could
    warn about this though. Please file an issue for go vet.

    --
    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.
  • Freedom Dumlao at Apr 29, 2014 at 9:10 pm
    The program is perfectly valid, if there isn't a return statement
    present, how could the compiler check the type of the returned value.

    That's not exactly true though, is it? In this example there is no return
    statement, and the compiler detects it and refuses to compile:

    http://play.golang.org/p/937AsyLoPg

    The only difference being that the earlier example included an infinite
    loop. I do agree that it should be something detected by go vet, and not
    necessarily the compiler. I just found it interesting since I can't seem to
    imagine a time when you would want to define a function with a return type
    that is guaranteed never to return at all.



    On Tue, Apr 29, 2014 at 4:13 PM, minux wrote:

    On Tue, Apr 29, 2014 at 2:58 PM, Freedom Dumlao wrote:

    I was surprised recently when I found a bug in my program that I would
    have expected to be caught by the compiler or "go vet".

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

    It appears that even if your function declares a return type, it will
    compile without a proper return of that type so long as there is an
    infinite loop.

    The behavior is documented here:

    http://golang.org/doc/go1.1#return

    I suppose I expected that the compiler would have failed to compile my
    program, or at least that "go vet" would have mentioned it since it seems
    unlikely that I'd actually want to declare a function with a return type
    but then implement the function in such a way as to never return any value
    whatsoever. (if you do have a return statement after the for loop, "go vet"
    will detect the unreachable code)

    Thought I'd share and I'd love to hear other's thoughts on this behavior.
    The program is perfectly valid, if there isn't a return statement present,
    how could the compiler
    check the type of the returned value.

    As soon as you add a way to break from the loop, the compiler will
    correctly complain that
    return statement is missing.

    It's not the compiler's job to stop you from writing this kind of
    programs, go vet probably could
    warn about this though. Please file an issue for go vet.
    --
    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.
  • Minux at Apr 29, 2014 at 9:19 pm

    On Apr 29, 2014 5:10 PM, "Freedom Dumlao" wrote:
    The program is perfectly valid, if there isn't a return statement
    present, how could the compiler check the type of the returned value.
    That's not exactly true though, is it? In this example there is no return
    statement, and the compiler detects it and refuses to compile:
    by no return statement present, i really mean the function can't return.
    http://play.golang.org/p/937AsyLoPg

    The only difference being that the earlier example included an infinite
    loop. I do agree that it should be something detected by go vet, and not
    necessarily the compiler. I just found it interesting since I can't seem to
    imagine a time when you would want to define a function with a return type
    that is guaranteed never to return at all.
    there are a lot of unreasonable but valid Go programs, should the compiler
    reject them all?

    how could you define unreasonable programs?

    --
    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.
  • Rui Ueyama at Apr 29, 2014 at 9:23 pm

    On Tue, Apr 29, 2014 at 2:10 PM, Freedom Dumlao wrote:

    The program is perfectly valid, if there isn't a return statement
    present, how could the compiler check the type of the returned value.

    That's not exactly true though, is it? In this example there is no return
    statement, and the compiler detects it and refuses to compile:

    http://play.golang.org/p/937AsyLoPg
    I think that the reason why the code fails to compile is not because of
    missing return statement but because fmt.Println() is a non-terminating
    statement [1]. On the other hand, an infinite for loop is a terminating
    statement.

    [1] http://golang.org/ref/spec#Terminating_statements


    The only difference being that the earlier example included an infinite
    loop. I do agree that it should be something detected by go vet, and not
    necessarily the compiler. I just found it interesting since I can't seem to
    imagine a time when you would want to define a function with a return type
    that is guaranteed never to return at all.



    On Tue, Apr 29, 2014 at 4:13 PM, minux wrote:

    On Tue, Apr 29, 2014 at 2:58 PM, Freedom Dumlao wrote:

    I was surprised recently when I found a bug in my program that I would
    have expected to be caught by the compiler or "go vet".

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

    It appears that even if your function declares a return type, it will
    compile without a proper return of that type so long as there is an
    infinite loop.

    The behavior is documented here:

    http://golang.org/doc/go1.1#return

    I suppose I expected that the compiler would have failed to compile my
    program, or at least that "go vet" would have mentioned it since it seems
    unlikely that I'd actually want to declare a function with a return type
    but then implement the function in such a way as to never return any value
    whatsoever. (if you do have a return statement after the for loop, "go vet"
    will detect the unreachable code)

    Thought I'd share and I'd love to hear other's thoughts on this behavior.
    The program is perfectly valid, if there isn't a return statement
    present, how could the compiler
    check the type of the returned value.

    As soon as you add a way to break from the loop, the compiler will
    correctly complain that
    return statement is missing.

    It's not the compiler's job to stop you from writing this kind of
    programs, go vet probably could
    warn about this though. Please file an issue for go vet.
    --
    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.
  • Matthew Kane at Apr 29, 2014 at 9:24 pm
    func doSomethingHopefullyForever() (err error) {
       defer func() {
         if r := recover(); r != nil {
           err = fmt.Errorf("%v", r)
         }
       }()
       for {
       }
       // still unreachable
    }

    func doSomethingForever() {
       for {
         log.Println(doSomethingHopefullyForever())
       }
    }

    func main() {
       go doSomethingForever()
       go doSomethingForever()
       go doSomethingForever()
       go doSomethingForever()
       select {} // block forever
    On Tue, Apr 29, 2014 at 5:10 PM, Freedom Dumlao wrote:
    The program is perfectly valid, if there isn't a return statement present,
    how could the compiler check the type of the returned value.
    That's not exactly true though, is it? In this example there is no return
    statement, and the compiler detects it and refuses to compile:

    http://play.golang.org/p/937AsyLoPg

    The only difference being that the earlier example included an infinite
    loop. I do agree that it should be something detected by go vet, and not
    necessarily the compiler. I just found it interesting since I can't seem to
    imagine a time when you would want to define a function with a return type
    that is guaranteed never to return at all.



    On Tue, Apr 29, 2014 at 4:13 PM, minux wrote:


    On Tue, Apr 29, 2014 at 2:58 PM, Freedom Dumlao <freedomdumlao@gmail.com>
    wrote:
    I was surprised recently when I found a bug in my program that I would
    have expected to be caught by the compiler or "go vet".

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

    It appears that even if your function declares a return type, it will
    compile without a proper return of that type so long as there is an infinite
    loop.

    The behavior is documented here:

    http://golang.org/doc/go1.1#return

    I suppose I expected that the compiler would have failed to compile my
    program, or at least that "go vet" would have mentioned it since it seems
    unlikely that I'd actually want to declare a function with a return type but
    then implement the function in such a way as to never return any value
    whatsoever. (if you do have a return statement after the for loop, "go vet"
    will detect the unreachable code)

    Thought I'd share and I'd love to hear other's thoughts on this behavior.
    The program is perfectly valid, if there isn't a return statement present,
    how could the compiler
    check the type of the returned value.

    As soon as you add a way to break from the loop, the compiler will
    correctly complain that
    return statement is missing.

    It's not the compiler's job to stop you from writing this kind of
    programs, go vet probably could
    warn about this though. Please file an issue for go vet.

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


    --
    matt kane
    twitter: the_real_mkb / nynexrepublic
    http://hydrogenproject.com

    --
    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.
  • Freedom Dumlao at Apr 29, 2014 at 9:41 pm
    Awesome. Great use case. Thanks Matthew!

    On Tue, Apr 29, 2014 at 5:24 PM, Matthew Kane wrote:

    func doSomethingHopefullyForever() (err error) {
    defer func() {
    if r := recover(); r != nil {
    err = fmt.Errorf("%v", r)
    }
    }()
    for {
    }
    // still unreachable
    }

    func doSomethingForever() {
    for {
    log.Println(doSomethingHopefullyForever())
    }
    }

    func main() {
    go doSomethingForever()
    go doSomethingForever()
    go doSomethingForever()
    go doSomethingForever()
    select {} // block forever
    On Tue, Apr 29, 2014 at 5:10 PM, Freedom Dumlao wrote:
    The program is perfectly valid, if there isn't a return statement
    present,
    how could the compiler check the type of the returned value.
    That's not exactly true though, is it? In this example there is no return
    statement, and the compiler detects it and refuses to compile:

    http://play.golang.org/p/937AsyLoPg

    The only difference being that the earlier example included an infinite
    loop. I do agree that it should be something detected by go vet, and not
    necessarily the compiler. I just found it interesting since I can't seem to
    imagine a time when you would want to define a function with a return type
    that is guaranteed never to return at all.



    On Tue, Apr 29, 2014 at 4:13 PM, minux wrote:


    On Tue, Apr 29, 2014 at 2:58 PM, Freedom Dumlao <
    freedomdumlao@gmail.com>
    wrote:
    I was surprised recently when I found a bug in my program that I would
    have expected to be caught by the compiler or "go vet".

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

    It appears that even if your function declares a return type, it will
    compile without a proper return of that type so long as there is an
    infinite
    loop.

    The behavior is documented here:

    http://golang.org/doc/go1.1#return

    I suppose I expected that the compiler would have failed to compile my
    program, or at least that "go vet" would have mentioned it since it
    seems
    unlikely that I'd actually want to declare a function with a return
    type but
    then implement the function in such a way as to never return any value
    whatsoever. (if you do have a return statement after the for loop, "go
    vet"
    will detect the unreachable code)

    Thought I'd share and I'd love to hear other's thoughts on this
    behavior.
    The program is perfectly valid, if there isn't a return statement
    present,
    how could the compiler
    check the type of the returned value.

    As soon as you add a way to break from the loop, the compiler will
    correctly complain that
    return statement is missing.

    It's not the compiler's job to stop you from writing this kind of
    programs, go vet probably could
    warn about this though. Please file an issue for go vet.

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


    --
    matt kane
    twitter: the_real_mkb / nynexrepublic
    http://hydrogenproject.com
    --
    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.
  • Martin Drlík at Apr 29, 2014 at 10:12 pm
    func Something() Something {

    for {}

    }
    is valid

    You're implementing some interface and you want to block Something forever.
    Actually I'm reapeating this converstation just to mention that if it's
    really intended you should put panic at the end. (I think it has been
    already mentioned by somebody).

    func Something() Something {
               for {}

    panic("unreachable")

    }

    vet can be implemented to warn you (or code reviewer) and you are still
    able to control it (prevent irrelevant warnings) by putting panic.

    On Tuesday, April 29, 2014 8:58:35 PM UTC+2, Freedom Dumlao wrote:

    I was surprised recently when I found a bug in my program that I would
    have expected to be caught by the compiler or "go vet".

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

    It appears that even if your function declares a return type, it will
    compile without a proper return of that type so long as there is an
    infinite loop.

    The behavior is documented here:

    http://golang.org/doc/go1.1#return

    I suppose I expected that the compiler would have failed to compile my
    program, or at least that "go vet" would have mentioned it since it seems
    unlikely that I'd actually want to declare a function with a return type
    but then implement the function in such a way as to never return any value
    whatsoever. (if you do have a return statement after the for loop, "go vet"
    will detect the unreachable code)

    Thought I'd share and I'd love to hear other's thoughts on this behavior.


    --
    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
postedApr 29, '14 at 6:58p
activeApr 29, '14 at 10:12p
posts9
users5
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase