golang Annoying Assignment syntax

[bronze man]

I have seen this thread:

http://stackoverflow.com/questions/16521472/assignment-operator-in-go-language

It is annoying to see "xxx.go:27: no new variables on left side of :="

I think there is no need to force to write ":=",if compile see a new variable,just declaration it...

Those stuff work fine in js,python,php...

I agree ":=" may be useful in some scope stuff.

[Ian Lance Taylor]

On Thu, Nov 21, 2013 at 9:11 AM, bronze man <bronz...@gmail.com> wrote:
>
> It is annoying to see "xxx.go:27: no new variables on left side of :="
> I think there is no need to force to write ":=",if compile see a new
> variable,just declaration it...
> Those stuff work fine in js,python,php...
> I agree ":=" may be useful in some scope stuff.

Experience with other languages is what leads Go to require := to
declare a variable. It means that if you accidentally misspell a
variable name on the left hand side of an assignment, you get a
compile-time error rather than a confusing debugging session.

Ian

[Aram Hăvărneanu]

What's golang?

--
Aram Hăvărneanu

[Kevin Gillette]

On Thursday, November 21, 2013 11:14:07 AM UTC-7, Aram Hăvărneanu wrote:

What's golang? 

It's the site where the spec lives. What's Go? Well obviously it's go.org!

On Thu, Nov 21, 2013 at 9:11 AM, bronze man <bronz...@gmail.com> wrote: 

It is annoying to see "xxx.go:27: no new variables on left side of :="

On Thursday, November 21, 2013 11:11:36 AM UTC-7, Ian Lance Taylor wrote:

On Thu, Nov 21, 2013 at 9:11 AM, bronze man <bronz...@gmail.com> wrote: 
> It is annoying to see "xxx.go:27: no new variables on left side of :=" 

I agree that it can be annoying when it causes edit thrashing. 

 

Experience with other languages is what leads Go to require := to 
declare a variable.  It means that if you accidentally misspell a 
variable name on the left hand side of an assignment, you get a 
compile-time error rather than a confusing debugging session.

I'd argue that the common class of misspelling errors is avoided not by the "no new variables" error, but rather by the "variable declared but not used" error (the latter of which is arguably much more valuable). For the "no new variables" error to prevent a bug, it seems the misspelling would have to result in an identical name to one that already exists in the same scope***, which is decreasingly likely as more characters form a given name, and increasingly likely to cause a type mismatch error anyway; alone, I suspect the "no new variables" error only really prevents a subclass of i <-> j <-> k single character misspellings in practice, which in my experience are less likely to be used in multiple assignment in such a way that misuse can be caught by any current compiler checks.

***Colon-equals creates errors too, particularly scoping errors, and partially compromises some of the intent of the "no new variables" error by not requiring that all variables in the declaration are new (this is a sacrifice, of course, made in the name of convenience).  There have been proposals, such as `:x, :y, z := ...` to declare x and y, but not z, which would though explicit individual declarations fix a number of the above issues (unintentional shadowing, compromise of intent, "no new variables"). It's certainly worth considering some improvement to variable declaration at least for Go 2, if and when that comes over the horizon.

[Alex Zorin]

I've on multiple occasion used `:=` by accident on an inner scope when a var of the same name had already been declared on an outer scope, and been left scratching my head. 

That said, on balance, it's very convenient.

[bronze man]

On Friday, November 22, 2013 4:58:47 AM UTC+8, Kevin Gillette wrote:

I'd argue that the common class of misspelling errors is avoided not by the "no new variables" error, but rather by the "variable declared but not used" error (the latter of which is arguably much more valuable). For the "no new variables" error to prevent a bug, it seems the misspelling would have to result in an identical name to one that already exists in the same scope***, which is decreasingly likely as more characters form a given name, and increasingly likely to cause a type mismatch error anyway; alone, I suspect the "no new variables" error only really prevents a subclass of i <-> j <-> k single character misspellings in practice, which in my experience are less likely to be used in multiple assignment in such a way that misuse can be caught by any current compiler checks.

 I think "variable declared but not used" is enough, "no new variables" seems never find actually problem in program