Skip to content

Comment on A nice, little known C feature: Static array indices in parameter declarationsparent

Comments

I agree that it's a pretty clean language, but it still has oddities. For example, where in your linked spec does it address why the following trips a compile error?

    func foo(b bool) {
        if b {
            return
        } else {
            return
        }
    }

    func bar(b bool) int {
        if b {
            return 100
        } else {
            return 200
        }
    }

    func baz(b bool) int {
        if b {
            return 100
        }
        return 200
    }

    func qux(b bool) int {
        if b {
            return 100
        } else {
            return 200
        }
        panic("?")
    }

    // Error: function [bar] ends without a return statement

Don't just link that with no comment. I thought you were disagreeing, not just showing that the go people have refused to fix it for two years.

To be fair, they have executed the overall project very well from what I've seen. A few things falling through the cracks is probably inevitable. That issue's not closed so there's hope for it yet.

OK, here's the expanded text for my comment (I didn't "show something" or disagree/agree -- I just provided reference):

"Here's this issue in Go bug tracker: https://code.google.com/p/go/issues/detail?id=65

Providing a link to the issue in the bugtracker, with discussion, is definitely "showing something".

I don't know, maybe I'm just weird, but when I see a comment replied to with a single link patterns suggest that it's a link disproving something. So I got confused until I had read the full page.

Is seems to be a bug but it could well be a feature. Requiring that functions end with a return statement is a good thing IMO. That avoids weird bugs if later the "else" is replaced by an "else if".

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.