1 min read
IncDec statements
IncDec statements The “++” and “–” statements increment or decrement their operands by the untyped constant 1. As with an assignment, the operand must be addressable or a map index expression. IncDecStmt = Expression ( "++" | "--" ) . Most commonly you’ll see ++ and -- used on a simple variable. But as explained, it’s not strictly limited to that. These operators can be used on any addressable (numeric) expression.
2 min read
Send statements
Send statements A send statement sends a value on a channel. The channel expression’s core type must be a channel, the channel direction must permit send operations, and the type of the value to be sent must be assignable to the channel’s element type. SendStmt = Channel "<-" Expression . Channel = Expression . Both the channel and the value expression are evaluated before communication begins. Communication blocks until the send can proceed.
2 min read
Expression statements
No livestream today. I wasn’t feeling well enough. No live stream next week either, as I’ll be traveling. Expression statements With the exception of specific built-in functions, function and method calls and receive operations can appear in statement context. Such statements may be parenthesized. ExpressionStmt = Expression . The following built-in functions are not permitted in statement context: append cap complex imag len make new real unsafe.Add unsafe.Alignof unsafe.Offsetof unsafe.Sizeof unsafe.
2 min read
Labeled statements
Today we’ll talk about labeled statements, which we’ve just recently mentioned in the context of terminating statements. Labeled statements A labeled statement may be the target of a goto, break or continue statement. LabeledStmt = Label ":" Statement . Label = identifier . Error: log.Panic("error encountered") If I may say so, the example provided is pretty bad. I mean, yeah, it technically is a labeled statement. It contains the label Error, followed by a colon (:), followed by a statement.
Subscribe to Boldly Go: Daily
Every day I'll send you advice to improve your understanding of Go. Don't miss out! I will respect your inbox, and honor my privacy policy.
Unsure? Browse the archive.
1 min read
Empty statements
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:
2 min read
Terminating statements conclusion
So we’ve made it through the list of 8 types of terminating statements. We conclude this section with a couple additional comments: Terminating statements … All other statements are not terminating. A statement list ends in a terminating statement if the list is not empty and its final non-empty statement is terminating. What is a statement list? It’s, well, eh… a list of statements! It’s not as interesting or profound as it sounds.
2 min read
Terminating labeled statements
Today’s live stream is starting an hour later than usual. Join me at 16:00, CEST, for some live Go coding using TDD. Terminating statements … A labeled statement labeling a terminating statement. Labeled statement’s are not used a lot in Go. Terminating labeled statements even less so. But they do exist, just the same. Here’s an example, using goto, and a labeled terminating statement. func foo() { if someCondition { goto end } fmt.
1 min read
Terminating select statements
Terminating statements … A “select” statement in which: there are no “break” statements referring to the “select” statement, and the statement lists in each case, including the default if present, end in a terminating statement. This is quite similar to the “switch” case we looked at yesterday. Let’s consider an example: select { case <-ctx.Done(): return ctx.Err() case msg := <-messageChannel fmt.Println(message) return nil } This select statement has two cases, each of which terminates (by virtue of returning).
2 min read
Terminating switch statements
Terminating statements … A “switch” statement in which: there are no “break” statements referring to the “switch” statement, there is a default case, and the statement lists in each case, including the default, end in a terminating statement, or a possibly labeled “fallthrough” statement. This should make good sense, but let’s look at an example, and a counter-example, to illustrate. func greet(args ...string) error { switch len(args) { case 0: return errors.
1 min read
Terminating for loops
Terminating statements … A “for” statement in which: there are no “break” statements referring to the “for” statement, and the loop condition is absent, and the “for” statement does not use a range clause. Put another way, a for statement is terminating if it either never ends (an infinite loop), or it unconditionally terminates. This one “bit” me the other day, as I was refactoring code for a client. (Speaking of clients—I have some availability starting in May for a new client.
1 min read
Terminating if statements
Last week we saw that a block that ends in a terminaging statement is itself a terminating statement. Today we expand a bit on that idea: Terminating statements … An “if” statement in which: the “else” branch is present, and both branches are terminating statements. In other words, the following counts as a terminating statement: if somethingInterestingHappened() { fmt.Println("Wow, that was interesting!") return } else { fmt.Println("That was boring.") return } Both branches of the if statement terminate, so the statement as a whole is a terminating statement.