On Friday, October 21, 2016 at 4:31:51 AM UTC+8, gri wrote: > > To answer the subject line question: No, short variable declarations are > not technically necessary. We could have chosen not to have them. But there > are good reasons for them. It was a deliberate design decision. > > Let me throw in a bit of historical perspective: > > Rob's invention of ":=" in one of his prior languages, and later, our > shared experience with ":=" in Sawzall ( > https://en.wikipedia.org/wiki/Sawzall_(programming_language)) led to the > desire of wanting ":=" in Go. Variable declaration and initialization is > among the most common statements written in an imperative programming > language (next to simple assignment), and ":=" worked beautifully and > succinctly for this purpose in the past, and it fit well into the overall > design of Go. > > The key here is that providing an initialization expression is mandatory > with ":=" (in contrast to "just" a variable declaration), and because it's > mandatory, we can omit the type of the variable (assuming we're ok with the > type of the initialization expression). > > At the same time we wouldn't simple give up ordinary variable > declarations, using the "var" keyword. For one, at the package level, a > free-standing (i.e., w/o introductory keyword) "v := x" would cause parsing > difficulties and be somewhat irregular compared to all other declarations. > > Thus, originally, "x := y" was simply very convenient syntactic sugar for > "var x = y" and both could be used interchangeably, in most places. Go has > little syntactic sugar, and where it has, it's because there's a lot of > "bang for the buck" - and that's certainly the case for ":=". > > The fact that "var x = y" is not permitted as a "for" loop initialization > statement was simply a design decision. Ian Taylor suggested that it's > "ugly". Aesthetics plaid a role here; and different people find different > things attractive. There's no hard technical reason why it couldn't be > permitted, it just isn't. > > Finally, the special rule permitting "redeclarations" with ":=" only came > in later. It gave short variable declarations different powers over regular > keyword-based variable declarations. While it was considered a very useful > new rule, it definitively distracted from the simple syntactic sugar > regularity. > > It is no secret that many people (including us) think that there may be > too many different yet similar ways of declaring and initializing variables > in Go; and it would be nice if a future Go could streamline and simplify > this. But we should also keep in mind that variable declaration and > initialization, next to simple assignment, are the most common statements > in program (it's one of the few things hardware can actually do directly, > which is moving data from a to b), so it does not seem unreasonable to have > various ways to express that, fine-tuned for each (relatively common) use > case. > > - gri > > Thanks, gri, this is almost the answer I want.
I still have two small questions about the short form. 1. would it be good to allow all identifiers in a short form are old ones (assume there is only one code block)? 2. would it be good/better to let identifiers in a short form not shadow outer block identifiers? I know the second one will break compatibility. It is not a feature request. It is just a plain question. > > On Thu, Oct 20, 2016 at 12:19 AM, T L <tapi...@gmail.com <javascript:>> > wrote: > >> >> >> On Thursday, October 20, 2016 at 3:25:18 AM UTC+8, Ian Lance Taylor wrote: >>> >>> On Wed, Oct 19, 2016 at 11:38 AM, Michael Jones <michae...@gmail.com> >>> wrote: >>> > As in a number of previous questions, this one was asked poorly and >>> the answers dance all around the intention. I had decided never to enter >>> the fray of these oddly-put assertion/half questions, but since this is >>> lingering, may I suggest that this is his real question: >>> > >>> > “can we have var-style declarations in the places where the shorthand >>> syntax is allowed?” >>> > >>> > elaborating… >>> > >>> > for i := 0; i < 10; i++ {…} >>> > >>> > might also allow >>> > >>> > for var i int; i < 10; i++ {…} >>> > >>> > and likewise in other short-variable-permitting contexts. >>> > >>> > Personally, it seems that the simplest argument in favor would be >>> orthogonality and the best argument in favor would be the natural creation >>> of multiple scope local variables. This “best” is not very strong, though, >>> since it is unclear to me how you could introduce variables of multiple >>> types. >>> > >>> > Not taking sides here…just feeling that the core issue was not >>> addressed. Nor was the much better question that was not asked, “why was >>> the decision made in Go not to allow non-short variable declarations in >>> these contexts?” >>> >>> Thanks for trying to clarify. >>> >>> I'm not sure I buy the orthogonality argument here. I mean, why not >>> permit any statement in the first clause of a for statement? Why >>> restrict it to just variable declarations? But if we accept that it >>> is restricted, I think it seems reasonable to restrict only to short >>> variable declarations, since `for var i int` seems to me to be ugly. >>> >>> You can create multiple local variables in the for scope by writing, for >>> example >>> for a, b := 0, 10; a < b; a++ { >>> (That would work with var, too). >>> >>> Ian >>> >> >> I think the short form should be used as a supplement for the normal var >> form, >> Specifically, short form should be used in the situation new variable >> identifiers and old variable identifiers are hybrid, >> or the situation only new variable identifiers exist. >> >> But now, the short form in an inner block will shadow variables in outer >> block. >> If we really want to shadow variables in outer block, then we can just >> use the normal var form. >> Now the design makes the short form compete with the normal var form. >> >> >> >> -- >> 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...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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.