Do we really need keyword "var"?

[i3dmaster]

As reading and writing a bit more Go programs, I found less and less
compelling to have keyword "var" around. Although its so far just my
personal experience, but I'd like to raise it up and see everyone's
feedback including the Go authors. If possible, could we get rid of
one more keyword... If we have to keep it, then whats the rationale
behind?

So looks like "var" can be used in:
var a int;
var a int = 1;
var a = 1;
var (
a := 1;
b := 2;
)

Can we replace them with:
a int;
a int = 1;
a = 1; (compile error, type must be present)
(
a := 1;
b := 2;
)
or
(a := 1; b := 2)

Are there any other use cases that I am not aware of? Do any of the
above amended version make the statement ambiguous or semantically
wrong by not using keyword "var"?

Plus, we've had the awesome short variable declaration which if IIRC
is recommended to use by Go authors, this "var" keyword even become a
bit useless I think...

[Matt Wartell]

Not having inspected the grammar, I expect that it is needed to work
"... without too many mandatory keywords, repetition, or arcana.
Second, the language has been designed to be easy to analyze and can
be parsed without a symbol table. This makes it much easier to build
tools such as debuggers, dependency analyzers, automated documentation
extractors, IDE plug-ins, and so on. C and its descendants are
notoriously difficult in this regard."

I'd be surprised if they put "var" in for no reason.

Source: http://golang.org/doc/go_lang_faq.html#different_syntax

[Ian Lance Taylor]

i3dmaster <i3dm...@gmail.com> writes:

> As reading and writing a bit more Go programs, I found less and less
> compelling to have keyword "var" around. Although its so far just my
> personal experience, but I'd like to raise it up and see everyone's
> feedback including the Go authors. If possible, could we get rid of
> one more keyword... If we have to keep it, then whats the rationale
> behind?

At the top level, every declaration begins with a keyword. This
simplifies parsing.

Within a function, there are a few cases where using var is simpler.

var v map[int]int;
SetMap(&v)

Ian

[i3dmaster]

On Dec 2, 10:28 pm, Ian Lance Taylor <i...@google.com> wrote:

> i3dmaster <i3dmas...@gmail.com> writes:
> > As reading and writing a bit more Go programs, I found less and less
> > compelling to have keyword "var" around. Although its so far just my
> > personal experience, but I'd like to raise it up and see everyone's
> > feedback including the Go authors. If possible, could we get rid of
> > one more keyword... If we have to keep it, then whats the rationale
> > behind?
>
> At the top level, every declaration begins with a keyword.  This
> simplifies parsing.

ok. I guess that makes sense.

>
> Within a function, there are a few cases where using var is simpler.
>
>   var v map[int]int;
>   SetMap(&v)

wouldn't

v map[int]int;
SetMap(&v)

simpler? (Essentially just a C reversed version)

So sounds like technically without it wouldn't bring semantically or
syntactically ambiguity to Go programs and it is just a parsing
performance gain right?

Another point is if we'd keep var, then maybe have it explicitly
require type declaration for variables would be a more clear syntax.

Consider var a = 1 and a := 1. I personally thing they have no
differences and a := 1 is much better syntactically. To gain a bit
compiling speed, I'd think that don't allow var a = 1 syntax. Would Go
authors consider the following declaration rules:
1. For all occurrences of using "var" keyword, a type must be present.
2. For all short declarations, type must not present.
3. All other cases yields compile error.


>
> Ian

[j-g-faustus]

I like 'var', and would definitely prefer to keep it - I use it almost
exclusively instead of the idiomatic short form, except in 'for' and
'switch':
var x = 42;
instead of
x := 42

Using var makes the code significantly more readable (i.e. scannable),
IMO. Having a fixed keyword in a fixed position (left margin) makes it
much quicker to scan a page of code to find the local variables, and
with a syntax highlighting editor you get the different color as
well.
In my experience, it's the difference between just glancing at the
code and actually having to read it :) (I found myself missing
something like a 'var' keyword in Ruby too.)

Go already lets you do it your way: Just stick to a personal coding
standard using var only for type declarations w/o assignment and :=
everywhere else.
For myself, I consider the current var syntax a Good Thing, and vote
to keep it.

[i3dmaster]

Having many personal coding style might not be a good thing though. I
think that's the reason for the born of most programming style guides.
Instead of letting people choose whatever style guide he/she might
feel better personally, there will almost always a common coding style
guide be established at some point. Then that becomes a topic of not
just how variable should be declared but also things like tab vs.
space, tab size, indentions, etc...

Back to my point, if we choose keeping "var", then being as a keyword
it should not be considered as an optional syntax style. If a := 1
valid and its the idiomatic way of doing variable declaration and
initialization, then the existence of var a = 1 becomes less
meaningful. You could argue that "while, you can't do a := 1 in the
top level", then I would think that require "var a int = 1" (require
the explicitly type declaration) would be better, then you will have
all use cases with var keyword distinct from cases of not using it
(not an option anymore). You wouldn't see occasionally 'var a = 1' in
some code where 'a := 1' from some others. Especially for beginners or
programmers who familiar with other languages that also happens to use
'var' keyword (such as javascript), it will introduce much less
confusing as of why some people use 'var a = 1' style and some use the
other. (btw, if you don't know javascript, then actually, it has a
different semantics bearing than what it is in Go. Declaring variables
using var keyword in Go has nothing to do with scope, but in
javascript, that's exactly what it means.)

It only requires one change, if you use 'var' keyword, then type
declaration is required. That's all. And after all, how many global
variable declarations we need for the use case of 'var a = 1' style?

[Ian Lance Taylor]

i3dmaster <i3dm...@gmail.com> writes:

> It only requires one change, if you use 'var' keyword, then type
> declaration is required. That's all. And after all, how many global
> variable declarations we need for the use case of 'var a = 1' style?

Lots of top level declarations currently omit the type. Why should
they bother to state it if the type of the initialization value is
correct?

Ian

[konrad]

var makes a difference when you use a var block with the iota keyword.

var {
a = iota;
b = iota;
c = iota;
}

results in a=0 b=1 c=3

while

a := iota;
b := iota;
c := iota;

will result in a=0 b=0 and c=0
note that first version can be more concisely written as

var {
a := iota;
b;
c;
}

iota is the go solution to building enumberated sets. as its a value
that gets incremented on every semi colon and reset to zero by every
var.

Also there are times when you want to declare a variable but not set
it to a value and the only way to do this is something like

var a int;

[SnakE]

2009/12/4 konrad <kziel...@gmail.com>

var makes a difference when you use a var block with the iota keyword.

var {
 a = iota;
 b = iota;
 c = iota;
}

iota is only defined within const definition.  Try to compile your example.

[konrad]

Indeed my bad. Looks like I didn't read the spec carefully enough. And
I've called other on that point previously.

On Dec 4, 10:33 am, SnakE <snake.sc...@gmail.com> wrote:
> 2009/12/4 konrad <kzielin...@gmail.com>

[i3dmaster]

On Dec 3, 3:16 pm, konrad <kzielin...@gmail.com> wrote:
> var makes a difference when you use a var block with the iota keyword.
>
> var {
>   a = iota;
>   b = iota;
>   c = iota;
>
> }
>
> results in a=0 b=1 c=3
>
> while
>
> a := iota;
> b := iota;
> c := iota;
>
> will result in a=0 b=0 and c=0
> note that first version can be more concisely written as
>
> var {
>    a := iota;
>    b;
>    c;
>
> }

It should be const, not var though. But if we just assume the language
does support var declaration block, what is technically impossible to
write like this?

(a := iota; b; c;)
OR
const (ca := iota; cb; cc;)

I believe either way, there is no ambiguity in parsing. I think Ian's
comment for introducing "var" keyword mainly is for consistency
(because all top level declaration starts with a keyword).

>
> iota is the go solution to building enumberated sets. as its a value
> that gets incremented on every semi colon and reset to zero by every
> var.
>
> Also there are times when you want to declare a variable but not set
> it to a value and the only way to do this is something like
>
> var a int;

Again, what would make it impossible to just do "a int;"? You got an
identifier and you got the type, that's all the compiler needs to know
to figure out the memory allocation I think. Still, in this case, var
is just for consistency.

[i3dmaster]

On Dec 3, 2:08 pm, Ian Lance Taylor <i...@google.com> wrote:

Yes, that's a fair question. But if the compiler is willing to spend a
little extra little cycle to figure out the type, what makes up the
reason for keeping "var" there too? Does "var" give the type info? Or
does it give anything to help figuring out anything?

I think technically, a = 1, or a = any_primitive (type can be
determined in compile time) does not really need either type or var
(if we are willing to let compiler do the best work). You've got
const, func, type, etc, the only thing left is variables. There is
impossible to make a such statement ambiguity to parse I believe. Am I
right? Then I think it goes back to your previous comment, its
probably for consistency and/or readability. Then I would probably
argue that "var a int = 1" actually adds more consistency and
readability. For consistency, people would not able to arbitrarily
pick var a = 1 or a := 1 by their own preferences (though in file
scope, only var a = 1 is allowed but that's just because the current
law made so, there is no logical reason one can't do a := 1 in top
level) and apparently in functions, we can use either. For
readability, one does not have to rely on parsing someone else's
different coding preference in order to understand the code but rather
conforming to a strict grammar law.

There is also a little bit of rise by doing var a = 1 style I think.
Because compiler can only link the most popular type to this
identifier, it may not be the actual one that the author really wants.
What if the author wants uint32 instead of int? This is actually
severer in Go because different primitive types are not
interchangeable. int, int32, uint32, etc are just complete different
types. It might be more vulnerable to get buffer overflowed.

>
> Ian

[i3dmaster]

Look at this example given from the lang spec

// A struct with 6 fields.
struct {
x, y int;
u float;
_ float; // padding
A *[]int;
F func();
}

No var is in the field declaration. Actually its a compile error if
you use var. Btw, this is not a valid Go code. It does not start the
declaration with "type" keyword and it does not give a type name. If
you just paste this code in, it will not compile. I'd recommend the
author to revise this section of the spec to make it a true Go code
though.

[gorgo...@online.de]

On Thu, 3 Dec 2009 22:30:44 -0800 (PST)
i3dmaster <i3dm...@gmail.com> wrote:


> if we just assume the language
> does support var declaration block, what is technically impossible to
> write like this?
>
> (a := iota; b; c;)
> OR
> const (ca := iota; cb; cc;)

the first can become a problem. remember that go uses a LALR(1) parser
(bison). in other words: it does just one lookahead. if you can end
a statement with optional () but also start a new statement in (), the
parser may not distinct these both cases but believe that the () belong
to the first statement. there are ways around that but they make the
language more tricky. it is thus more safe to start all statements with
a term (variable name or keyword).



--
GorgonZola <gorgo...@online.de>

[i3dmaster]

That's a good point.

On Dec 4, 4:01 am, gorgonz...@online.de wrote:
> On Thu, 3 Dec 2009 22:30:44 -0800 (PST)
>

> GorgonZola <gorgonz...@online.de>

[Rowan Davies]

I'd add that LALR(1) is easier to implement in homosapien wet-ware.

You can approximate more complex grammers without much effort on that
platform. But, the limits of the approximation will be costly when
tested. LALR(1) allows a much more robust approach - you can formulate
some relatively local rules as sanity checks in your wet-ware.

My own implementation on this platform increasingly does not scale to
the complex types in in C++, Java, C# etc. Already the prototype I'm
using for Go seems more robust.

- Rowan

[OwlHuntr]

var is in the specs so why not use it? It does have times when it's
definitely useful or necessary such as defining variables but not
using them, skimming code, and the block definition with iota and the
LALR(1) situation brought up earlier. I'd stick with just using it to
be on the safe side, it can't hurt.