On Thu, Oct 13, 2016 at 9:40 AM, <d...@veryhaha.com> wrote: > > On Friday, October 14, 2016 at 12:14:34 AM UTC+8, Ian Lance Taylor wrote: >> >> On Thu, Oct 13, 2016 at 8:36 AM, <di...@veryhaha.com> wrote: >> > >> > On Thursday, October 13, 2016 at 11:24:50 PM UTC+8, Jesper Louis >> > Andersen >> > wrote: >> >> >> >> The rule is that a short variable declaration requires that at least >> >> one >> >> non-blank variable is new (the specification even says so) Consider >> >> >> >> _, y := 4,5 >> >> >> >> where one variable, y, is new. In >> >> >> >> _ := 6 >> >> >> >> or >> >> >> >> _, _ := 5, 7 >> >> >> >> this rule is violated, since there are no non-blank variables (and thus >> >> vacuously nothing new). >> >> >> >> I think the reason this is a rule is because it may detect some >> >> spurious >> >> errors by forcing the programmer to write code in a certain style, but >> >> I may >> >> be wrong. >> > >> > >> > >> > What spurious errors? >> >> The error of thinking that because you are using := you are getting a >> new variable. >> >> The handling of := is a bit tricky, perhaps too tricky. It used to >> always declare new variables, and give an error if there was already a >> variable of the same name in the same scope. But that was too painful >> to use with the err variable, because of the common use of >> n, err := F() >> So := was changed to permit reusing a variable if it already existed >> in the same scope with the same name and (inferred) type. > > > But the long variable declaration form only allows all variables are new > ones generally, except for the blank _ identifier. > Why not also make an exception for the blank _ identifier in the short form?
Every language change has a cost and a benefit. The cost of this change is that right now we have a simple rule: a := statement must define at least one new variable. You are suggesting that we replace that with a more complicated rule: a := statement must define at least one new variable, except in the case where all the variables are the blank identifier, in which case it is OK. Also, the language is stable, so any change at all carries a cost. The benefit of this particular change seems to me to be very very small: when you have an existing `a, _ := b, c` statement, you can change it to `_, _ := b, c` instead of changing it to `_, _ = b, c`. I don't see why the very small benefit outweighs the cost. I'm just speaking for myself, of course. If this is important to you, you could write this up as a language change proposal, describing the change and presenting an argument for why the benefit outweighs the cost. See https://github.com/golang/proposal . But I suspect that such a proposal would be rejected unless the argument in favor was quite convincing. Ian -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
