On Friday, October 21, 2016 at 11:26:46 PM UTC+8, T L wrote:
>
>
>
> 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.
>
how about adding a ::= operator to satisfy above two rules?
>
>
>>
>> On Thu, Oct 20, 2016 at 12:19 AM, T L <tapi...@gmail.com> 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.
>>> 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.
