Empty statements

April 10, 2024

Empty statements

The empty statement does nothing.

EmptyStmt = .

I don’t think there’s much to say here. I suppose we could spend some time debating if/when an empty statement exists in our code. How many empty statements in the following?

Is it one? Zero? An infinite number?

How many “nothings” does this code do?

I can honestly say I’m not sure why “the empty statement” is even defined. It’s only mentioned four other times in the spec, once as one of the possible components of a simple statement:

SimpleStmt = EmptyStmt | ExpressionStmt | SendStmt | IncDecStmt | Assignment | ShortVarDecl .

And then three other times, in contexts similar to the one mentioned yesterday, where it’s mentioned in the context of “the last non-empty statement” in a list.

All in all, it seems this concept could have been left out of the spec without any ill effect. 🤷

In any case, you don’t really need to concern yourself with the empty statement. You’ll never use one. Or you’ll always use a countless number of them. I don’t know. It doesn’t matter. LOL

Quotes from The Go Programming Language Specification Language version go1.22 (Feb 6, 2024)


Share this

Direct to your inbox, daily. I respect your privacy .

Unsure? Browse the archive .

Related Content


Error structs

The standard library gives us only very basic error capabilities. For the most part, we can create strings-as-errors: return errors.New("oh no") And we can wrap errors with additional textual context: if err := doSomething(); err != nil { return fmt.Errorf("doSomething: %w", err) } But the fact that the built-in error type is an interface gives us a ton more flexibility than this to include arbitrary information with our errors. There are a few ways we can include additional information in errors, and I’ll go over a few of them.


100 episodes of Cup o' Go!

Yesterday, Shay Nehmad and I, and close to 20 other people, recorded the 100th episode of the Cup o’ Go podcast. It’s been just over two years since the first episode came out, and in that time we’ve made some good friends, and built a bit of a community. If you haven’t listened yet, I invite you to listen to the replay of the live episode, which is also about celebrating the newly released Go 1.


Constant errors

Last week I talked about how to create your own errors. Expanding on that idea, here’s a trick I like to use: Constant errors! Constants in Go are limited to simple underlying types: bool, string, and the numeric types. If we create our own type, which both satisfies the error interface, and has such an underlying type, we can then create constant error values: type errString string func (e errString) Error() string { return string(e) } const ErrTooManyFrogs = errString("too many frogs") Okay.

Get daily content like this in your inbox!

Subscribe