Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: Go 2: have only one way of declaring variable instead of two #29081

Closed
hinstw opened this issue Dec 3, 2018 · 16 comments
Closed

proposal: Go 2: have only one way of declaring variable instead of two #29081

hinstw opened this issue Dec 3, 2018 · 16 comments
Labels
FrozenDueToAge LanguageChange Proposal v2 A language change or incompatible library change
Milestone

Comments

@hinstw
Copy link

hinstw commented Dec 3, 2018

Currently there are two ways of declaring a variable in code:

x := 1
var x = 1

This is inconsistent. Every developer is free to use either style in their code
Proposal: have only one way of declaring variable, either var or :=

@gopherbot gopherbot added this to the Proposal milestone Dec 3, 2018
@bcmills
Copy link
Contributor

bcmills commented Dec 3, 2018

This proposal needs more background: what is the benefit that would outweigh the cost of updating ~all of the existing Go code?

@bcmills bcmills added LanguageChange v2 A language change or incompatible library change labels Dec 3, 2018
@bcmills
Copy link
Contributor

bcmills commented Dec 3, 2018

Also note that the two forms are not entirely redundant today.
The := form can be used with unexported types:

package a

type token […]
func Generate() token { […] }
package b

func Snoop() {
	t := a.Generate()  // t has type a.token, but the name 'a.token' cannot be used explicitly within b.
	[…]
}

The var form can be used to promote a constant or a value of a literal type to an equivalent defined type (https://play.golang.org/p/LnfQ_voi-pS), while ensuring that the build will break if the value is not actually assignable — even if it could be converted explicitly (https://play.golang.org/p/rQLB7Sap3PA).

@urandom
Copy link

urandom commented Dec 3, 2018

@bcmills

Wouldn't that also work with var as well

var t = a.Generate()

@deanveloper
Copy link

I think one of the things I like about Go is that there is typically only one way to write the same program (ie not having built-in streams). This proposal would break nearly every Go program, but it comes at the benefit of there being fewer ways to declare a variable. If this goes through, since var can do everything := can do (and more), we remove :=.

@bradfitz
Copy link
Contributor

bradfitz commented Dec 3, 2018

Duplicate of #377? At least close enough.

@deanveloper
Copy link

That one seems more concerned about shadowing, and changing the := operator to fix that issue, this issue seems to be more around completely removing either := or var ... so that there is only a single, consistent style to declare a variable.

@gertcuykens
Copy link
Contributor

I'm also in favor and think most core developers are but I think during Go1 design they actully tried really hard to do just that but they where stuck when it comes to pointer stuff, for example
https://play.golang.org/p/Uu9BQY9yNB1

package main

import (
	"fmt"
)

func main() {
	x := new(int)
        var y *int
	fmt.Println(x, y)
}

0x416020 <nil>

@ianlancetaylor
Copy link
Contributor

We need var at top level because every top level statement starts with a keyword. Since we have var at top level, we want it within functions.

We want := within functions because it is more concise.

In any case a change like is simply impossible to make at this point. It would break every existing Go program and invalidate all existing Go documentation and examples. There just isn't any benefit here that is worth that cost.

@dy-fi
Copy link

dy-fi commented Dec 3, 2018

The := assignment operator is only allowed in a function scope. I imagine this was implemented because they want global variables to have to be explicitly initialized. Also, := is easy and shouldn't be removed for the sake of simplicity but there also needs to be a way to explicitly declare variables and variable types.

@houd1ni
Copy link

houd1ni commented Dec 4, 2018

There're two completely different things: (variable declaration) and (same + assignment at once).

Completely useless and breaking change.

@deanveloper
Copy link

There're two completely different things: (variable declaration) and (same + assignment at once).

name := value is the exact same as var name = value.

I don't like this proposal too much (since it would, ya know, break nearly every Go program), but saying they are completely different is just not correct.

@themeeman
Copy link

We definitely shouldn't change var for package level variables. That should stay the same.

As for local variables, the main issue is that they both have exclusive benefits; var allows you to easily get the zero value of a type, while := lets you do any other kind of assignment. If we were to remove var, we would have to make an easy way to get the zero value of a type with :=; but at that point, instead of having two ways of declaring variables we have one way and a special case of that way.

I believe we should leave this as one of the quirks of Go, locking it down and throwing away the key as something that we shouldn't change.

@urandom
Copy link

urandom commented Dec 5, 2018

while := lets you do any other kind of assignment

What do you mean by this?

@themeeman
Copy link

@urandom Apologies for not being specific. I meant that := is optimized in terms of length and usability for most initialisations, like a := 50, as opposed to var a = 50.

@akyoto
Copy link
Contributor

akyoto commented Dec 6, 2018

I love the := syntax because it's short & simple.
I only use var when explicitly needed and it is simply required in some cases as a type declaration.

The consistency benefits exist but they are not worth the huge cost.

I would go as far as to say I would stop using Go if var became the only method of defining variables since the concise variable definition is such a core element of the language.

@ianlancetaylor
Copy link
Contributor

Thanks, but as I said above, we can't make this change to the language at this point.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge LanguageChange Proposal v2 A language change or incompatible library change
Projects
None yet
Development

No branches or pull requests