proposal: Go 2: empty as an alias for struct{}

[jimsnab]

Very simple proposal here.

Instead of:

// var m map[int]struct{}
m := map[int]struct{}{}
m[0] = struct{}{}

how about

// var m map[int]empty
m := map[int]empty{}
m[0] = empty{}

I love the change from interface{} to any, making code, stacks, intellisense, etc., easier to read.

I dislike the struct{}{} to represent the concept of an empty value.

I propose empty because it reduces curly brace clutter, and makes it obvious that the value is nothing.

[ianlancetaylor]

I suspect that interface{} is used a lot more often than struct{}.

[jimsnab]

I suspect that interface{} is used a lot more often than struct{}.

Well sure, but map[any]struct{} is a ubiquitous set.

interface{} was an overloaded concept for "anything", and struct{} was and is an overloaded concept for "nothing". One was fixed...

Anyway it would just be nice. It took me a little while to discover struct{} would be a better 'set' value than, say, a useless bool or other dummy value.

[bcmills]

The conventional name for this type in other languages is unit, not empty.

[DeedleFake]

I suspect that interface{} is used a lot more often than struct{}.

And I expect that the usage will go down as more generic implementation of things, such as sets, are created and added to various places. The most common direct usage will probably be in chan struct{}s.

[jimsnab]

The frequency-of-use argument is orthogonal. I have more struct{}{} in my code than goto.

[ianlancetaylor]

I don't think the frequency argument is unimportant. We could introduce all kinds of predeclared names. Each one is a tax on everyone in the Go community, because they have to learn it and remember what it means. Therefore, the bias should always be against adding a new name. They should only be added when they bring a significant benefit. An example of such a benefit would be that it makes a lot of existing code easier to read.

[jimsnab]

Nicely put.

These are all good points:

• How a new keyword impacts existing code
• How much code will it improve
• Will it make the language easier to learn

I don't think the answer to these has anything to do with how much another language construct is used.

An empty struct declaration is an unexpected way to declare an empty value, which in my mind has nothing to do with structs. Enough said, it was fun to think about this morning...

[DeedleFake]

How a new keyword impacts existing code

This is actually a non-issue here. unit or empty wouldn't be a new keyword, but a predeclared identifier, which means it can be shadowed and is thus 100% backwards compatible. That's why adding any wasn't a problem, either.

[arp242]

Some rough counts on my code code, Go stdlib, and contents of my module cache:

rg -F 'struct{}'                          6,572
rg -F 'interface{}'                      19,259
rg -g '*.go' '(\bany\{\b|, any|any,)'     3,973

It seems interface{} is about 4 times as common, give or take a bit. Not fully accurate, but seems about right and should be roughly in the right ballpark.

Is that enough to warrant adding a new predeclared identifier? I don't know. But I did have to explain what this odd "struct{}{}" thing means to a few junior devs over the years; it's kind of non-obvious, and IMHO rather ugly. On the other hand, you'd also have to explain what empty or unit means (especially unit is rather non-obvious).

[DeedleFake]

especially unit is rather non-obvious

unit would be obvious to Kotlin developers, as that's what it's called in there, though it also doubles as Kotlin's version of void. I haven't seen many equivalents in many other languages, though. I think Rust usually uses an empty tuple, (), to represent an empty type. Dart uses void itself, such as Future<void>.

If something like this is considered, a corollary that I'm not entirely sure about myself could be to allow a type name to be used directly as its own zero value. That would mean that var v unit = unit would be legal, as would v := time.Time. Those are all illegal right now because type names can't be used as values, not including the exceptions of make() and new().

[zigo101]

I believe in most struct{} use cases, people just need a zero-size type.
They don't care about the type is struct{} or [0]any.
So maybe it is better to call it zerosize?

[edit]: maybe zerocomp (means zero compisite) is better, so that zerocomp{} denotes the zero value.

[DeedleFake]

I think the opposite. The fact that it has no size is a minor optimization detail. I think most people are more interested in the fact that it contains no useful information.

[zigo101]

struct{} is a struct kind, that is a piece of information. ;)

Maybe

// var m map[int]_
m := map[int]_{}
m[0] = _

is a better choice by this logic?

[ianlancetaylor]

It's easy to write type empty = struct{}. We see in the conversation above that the name empty is confusing--some people think of it as analogous to nil rather than being a specific struct type.

The existing name any is different, as empty interfaces are widely used, and their use as a generic constraint is compelling.

Also the emoji voting is not in favor.

Therefore, this is a likely decline. Leaving open for four weeks for final comments.

[jimsnab]

The hope was to drive it to a standard, and not have type unit = struct{} here and type nothing = struct{} there. (Ok who's doing that, probably no one. Issue to me is largely just learning about messy and unclear struct{}{} and accepting it.)

Yes "any" is different, although... type any = interface{} was a way to go.

Likely decline due to emoji voting makes sense.

[ianlancetaylor]

No change in consensus.