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.
