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.
1 min read
Happy April Fool's Day
I’ll be streaming some live coding again, on this April Fool’s day. No joke. I hope you’ll join me. It’s April Fool’s day. And I also recently learned of #AprilCools – the idea of doing something off-topic, but serious, rather than cringey on April first. So this year, I, eh… extended my “Learn Go” book review series to review a book about learning Go…. the game, not the language. Have a watch.
1 min read
Terminating blocks
Terminating statements … A block in which the statement list ends in a terminating statement. What exactly does this mean? It means that if you have an (explicit) code block that ends in a terminating statement, the block itself is considered a terminating statement. Confused? How about an example: func foo() { if somethingInterestingHappened() { fmt.Println("Wow, that was interesting!") return } fmt.Println("That was boring.") } In this example, return is a terminating statement, as we saw [two days ago](/ archive/2024-03-27-terminating-statements/).
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.
3 min read
Don't panic!
Later today, at 15:00 UTC, I’ll be joining Denis Čahuk and Adrian Stanek on their regular Livestream, Our Tech Journey, to talk about TDD, Go, and do some live coding. Join us! The second in our list of terminating statements is… panic! Terminating statements … A call to the built-in function panic. Don’t panic. Don’t panic is such ubiquitous Go advice that it’s one of the famous Go proverbs. So why do we have a built-in panic function if we’re not supposed to use it?
1 min read
Terminating statements
Terminating statements A terminating statement interrupts the regular flow of control in a block. The following statements are terminating: A “return” or “goto” statement. The return statement should be familiar to virtually everyone. And the fact that it interrupts the regular flow of control should be no surprise: func foo() { fmt.Println("Hello there") return fmt.Println("You'll never see me!") } In this above example, the second fmt.Println is never called for fairly obvious reasons: The preceeding return statement interrupts the flow, and returns control control flow back to whatever code called foo() in the first place.
1 min read
Statements
At long last, we have completed the section of the spec on expressions… and now we move on to: Statements Statements control execution. Statement = Declaration | LabeledStmt | SimpleStmt | GoStmt | ReturnStmt | BreakStmt | ContinueStmt | GotoStmt | FallthroughStmt | Block | IfStmt | SwitchStmt | SelectStmt | ForStmt | DeferStmt . SimpleStmt = EmptyStmt | ExpressionStmt | SendStmt | IncDecStmt | Assignment | ShortVarDecl . In my experience, the terms “expression” and “statement” and “declaration” are often confused and conflated.
2 min read
Order of evaluation and floating point numbers
Today I’ll be live streaming again! This time, picking up where we left off last week, and adding another feature to my new Go code rewriter and simplifier. Join me! Order of Evaluation … Floating-point operations within a single expression are evaluated according to the associativity of the operators. Explicit parentheses affect the evaluation by overriding the default associativity. In the expression x + (y + z) the addition y + z is performed before adding x.