2 ms·
I actually had a subtle bug caused by variable shadowing. The current behaviour of := is error prone and IMO should be revisited. The situations where it clea
by YZF 11y ago
I actually had a subtle bug caused by variable shadowing. The current behaviour of := is error prone and IMO should be revisited. The situations where it cleans things up are offset by situations where it doesn't work (including in compound statements where it often ends up being I'd like to declare and check err but I also want to be able to use the other variable if err==nil).
Another thing not mentioned is type switches, that feels like something that was duct taped onto the language. I think it would have been better to be able to use .(type) anywhere (e.g. in an if statement) and not have some sort of special switch statement. So make types more of a first class thing. It's obviously more work though but there is probably some middle-ground there that would make it seem less like a hack.
I think the behaviour of slices is reasonable given that they are not as high level as they are in some other languages. They're basically a slightly nicer facade over pointer arithmetic and they are designed for efficiency and performance. I think overall they're fine. The "..." is a little awkward (appends could be a little nicer).
Just use goimports to and you won't see unused import errors any more. Works for me and makes things cleaner.
All in all I think there are some rough corners that could use a little polish but that can still happen, it's a new language after all. It's good enough to be really useful.
- Animats 11y agoYes, the semantics of ":=" for the multiple-variable case are just weird. You can create one variable and assign another, and it's invisible what's happening. Not too good. Variable shadowing is probably a misfeature anyway. If shadowing were an error, sometimes you'd have to change a local variable name. No big deal. An amusing alternative would be to require that any name imported into a block must be at least 3 or 4 characters long. You don't want short global variable names anyway; if "x" is a global variable, something is wrong. Then short local variable names could never clash.
- echlebek 11y agoThe behaviour you are talking about isn't anything to do with :=. It's just how scoping works in Go. := is just syntactic sugar. http://play.golang.org/p/bh6pm_8s9S http://play.golang.org/p/bh6pm_8s9S
- YZF 11y agoProbably the root of the issue is that it's slightly more complicated than syntactic sugar: "Unlike regular variable declarations, a short variable declaration may redeclare variables provided they were originally declared earlier in the same block (or the parameter lists if the block is the function body) with the same type, and at least one of the non-blank variables is new. As a consequence, redeclaration can only appear in a multi-variable short declaration. Redeclaration does not introduce a new variable; it just assigns a new value to the original." I.e. the mix of declaration with re-declaration. I agree it doesn't seem like much but it ends up causing needless confusion. If there was a more explict way of doing this, e.g.: x, var y = 1, 2 // y explicitly declared maybe that would be better. not sure.
- bkeroack 11y agoThis is what enables the idiom "foo, err := DoSomething()" where err is declared previously. Without the mixed declaration/redeclaration you'd have to either declare a different error variable every time in the block, or explicitly declare your result variable: foo1, err1 := DoSomething() foo2, err2 := DoSomething2() // or var Foo foo var err error foo, err = DoSomething() foo, err = DoSomething2()