* T L <tapir....@gmail.com> [161109 05:18]:
> On Friday, October 21, 2016 at 11:26:46 PM UTC+8, T L wrote:
> > 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?

The first one would definitely not be a good design.  The problem with
the short variable declaration is that you cannot tell by looking just
at that one line of code which variables are being redeclared and which
continue to refer to a previously existing variable.

Implementing the second one would only be good if it were part of fixing
the real problem, that is adding a new syntax that allows a single
combined assignment/declaration which requires each variable on the left
side to be individually identified as either a new (possibly shadowing)
variable or an existing variable that is not to be shadowed.

This has been discussed before, and does not seem likely to ever happen.

I go out of my way to avoid := when I can, to the point of writing

    var x int
    x, err = foo()

instead of

    x, err := foo()

when err has been declared earlier in that block.  There is no ambiguity
in the code on top; in the bottom statement, you have to look through
the source to find (or not find, which is more of an issue) both x and
err.

In the single variable case, where there is no ambiguity,

    var x = foo()

is only three more characters than

    x := foo()

and is _much_ easier to distinguish as a declaration rather than
assignment, especially for those of us who have experience in many
languages, where := can mean different things in different languages.
It is simply an issue of cognitive load.

...Marvin

-- 
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.

Reply via email to