proposal: Go 2: universal zero value with type inference

[geraldss]

I propose a universal zero value with type inference. Currently nil is a zero value with type inference for pointers and built-in reference types. I propose extending this to structs and atomic types, as follows:

{} would represent a zero value when the type can be inferred, e.g. in assignments and function call sites. If I have a function:

func Foo(param SomeLongStructName)

and I wish to invoke Foo with a zero value, I currently have to write:

Foo(SomeLongStructName{})

With this proposal, I could alternatively write:

Foo({})

For assignments currently (not initializations; post-initialization updates):

myvar = SomeLongStructName{}

With this proposal:

myvar = {}

This proposal is analogous to how nil is used for pointers and reference types.

The syntax allows type names and variable types to be modified without inducing extraneous code changes. The syntax also conveys the intent "zero-value" or "default" or "reset", as opposed to the actual contents of the zero value. Thus the intent is more readable.

[geraldss]

Or perhaps underscore as the zero designator. Either would be readable.

[jimmyfrasche]

Related issues #19642 now closed which proposed a universal zero value and #12854 which would allow type names to be elided in composite literals allowing all the examples in the first post.

[beoran]

Interesting idea. Sorry to bike shed, but perhaps the reusing the default keyword would be more readable?

Foo(default)
myvar = default

[geraldss]

Foo(default, default, default)
Foo({}, {}, {})
Foo(_, _, _)

I find the latter two more readable, but default or other keyword is also fine with a syntax highlighter. As jimmyfrasche pointed out, the {} and _ syntax have been proposed previously.

Here's another argument for the proposal. These calls highlight the values that are being passed, which is good:

Foo(10, "xyz", nil)
Foo({})

This call highlights the type that is being passed, including its fully qualified name. This shifts the cognitive effort.

Foo(SomeLongStructName{})

[quenbyako]

i think Foo({}, {}, {}) is more readable, than default, FMIO, cause 1) default has a bit more letters... cause, you know, less letters -> better code 🙃 2) create new reserved word is not a good idea, i know so many projects with default variables, so, it can break a lot of code base. Also _ symbol is for another things, like /dev/null in golang universe. so, with _ symbol as empty struct definition is not a good idea, i think.

but as a concept of language proposal, i like your idea.

[ianlancetaylor]

This seems to be a restatement of #19642 with a different spelling of the zero value. Given that the earlier proposal was not accepted, what has changed since then?

[geraldss]

It's not stated why the previous proposal was closed, and I had not seen it when I searched and filed this proposal.

I raised this proposal from direct and repeated experience. In addition to comments in this issue and the previous issues, I'll add another:

There are up to three items of information in a Go expression or assignment: name, type, and value.

1. Names are inferred using uniform rules across all Go datatypes. That is, names are inferred in assignments, function calls, and return statements, and the inference behavior is uniform across all Go datatypes.

2. Values are not inferred. This is also uniform.

3. Type inference is not universal and uniform, and it's not clear to me why that is.

The function calls FooInt32(0), FooInt64(0), FooPtr(nil), FooChan(nil), FooMap(nil) will all infer the argument type correctly. Presumably Golang believes that type inference is beneficial or ergonomical. These could all require explicit typing, e.g. int32(0).

[ianlancetaylor]

0 is an untyped constant, as are "", true, and false, and, for that matter "abc", 100, and 1+2i. Untyped constants may be used with any compatible type. If there is no compatible type, as in a := 0, they have a default type.

nil is the zero value of pointer, slice, channel, map, and function types. It is not an untyped constant: a := nil is an error. nil is in effect an overloaded term for the zero value of certain types. This overloading is problematic; see #22729. Note that for the types with which nil can be used, there is no other way to write the zero value.

This proposal, and #19642, is something else again. It proposes a way of writing a value that can be converted to the zero value in a type context. Writing a := {} would be an error. But we could write F({}), a = {} (for an already defined a), a == {}, return {}. For ordered types we could write a > {}. And while {} could be used with any type, it would always be an alias for the actual zero value of that type (0, false, nil, S{}, etc.).

You could presumably write 0 == {}, which would always be true: the 0 would have no type context so it would default to int, at which point {} would default to the value 0 in type int. Maybe you could write {} == 0. I'm not sure. I'm also not sure about 1 + {} and {} + 1. Or "a" + {} and {} + "a".

So I don't agree with your suggestion that there is some missing aspect to type inference. Untyped constants, nil, and {} are three different kinds of things.

[geraldss]

Per your comment, untyped constants do support type inference, and overloaded nil does support type inference (issue with nil interfaces noted).

The net effect of this is that type inference is neither uniform nor universal across data types. This is the impetus for my proposal and the earlier proposals. I also like #12854, and would consider any of these a positive step.