4 ms·
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 e
by frou_dh 14y ago
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
- dchest 14y agohttps://code.google.com/p/go/issues/detail?id=65 https://code.google.com/p/go/issues/detail?id=65
- Dylan16807 14y agoDon'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.
- frou_dh 14y agoTo 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.
- dchest 14y agoOK, 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 https://code.google.com/p/go/issues/detail?id=65
- Dylan16807 14y agoProviding 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.
- laurent123456 14y agoIs 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".