Initialization dependencies

Here’s a thing you’ve likely never thought about: What if you have a compound assignment statement, where one of the variables depends on the other in the same statement. That’s what we’re looking at today. Order of Evaluation … At package level, initialization dependencies override the left-to-right rule for individual initialization expressions, but not for operands within each expression: var a, b, c = f() + v(), g(), sqr(u()) + v() func f() int { return c } func g() int { return a } func sqr(x int) int { return x*x } // functions u and v are independent of all other variables and functions So first notice that calling f() returns c, and calling g() returns a.


Unordered evaluation

Yesterday’s spec quote included a sentence we breezed over. Today we’re going to dig in a bit more: Order of Evaluation … the order of those events compared to the evaluation and indexing of x and the evaluation of y and z is not specified, except as required lexically. What exactly does that mean? Well, the example that follows in the spec makes it a bit more clear, but in a nutshell, the order of evaluation for index expressions is not defined.


Order of Evaluation

Let’s talk about… the order of evaluation! You might think you have a strong grasp on this concept, but many languages have their own nuanced take on evaluation order in some cases. And then JavaScript has “hoisting”, which kinda spits in the face of order of evaluation. Before we dive in, here’s a short pop-quiz. What does this short program output when executed? package main import "fmt" func init() { fmt.


Constant expressions, part III

Did you miss yesterday’s Ask-me-anything session? You probably did. I had about 10-15 people there. But even with a small group, we had a ton of great questions! The Q&A session lasted about an hour, and covered topics such as book recommendations for going deeper into Go, what project to build to learn concurrency, and much more. Catch the replay on YouTube. Let’s continue our discussion of constant expressions, with some more miscellaneous rules:


Constant expressions, continued

Today I’ll be answering your questions on my weekly live stream. Have a question about Go? About CI/CD? About my favorite pizza toppings? Join me! Or submit your question early and catch the replay, if you can’t join live. Today we continue the section on Constant expressions, with a grab bag of miscellaneous rules. Constant expressions … Applying the built-in function complex to untyped integer, rune, or floating-point constants yields an untyped complex constant.


Constant expressions

We made it through all the conversion rules! Let’s change gear and talk about… Constant expressions Constant expressions may contain only constant operands and are evaluated at compile time. Or framed differently: Any expression that contains non-constant operands, is not a constant expression. If you have a constant expression (e.g. 1 + 2) then extend it with a non-constant operand (e.g. 1 + 2 + userCount()), then it is no longer a constant expression.


Conversions from slice to array or array pointer

Conversions from slice to array or array pointer … Converting a slice to an array yields an array containing the elements of the underlying array of the slice. Similarly, converting a slice to an array pointer yields a pointer to the underlying array of the slice. In both cases, if the length of the slice is less than the length of the array, a run-time panic occurs. s := make([]byte, 2, 4) a0 := [0]byte(s) a1 := [1]byte(s[1:]) // a1[0] == s[1] a2 := [2]byte(s) // a2[0] == s[0] a4 := [4]byte(s) // panics: len([4]byte) > len(s) s0 := (*[0]byte)(s) // s0 !

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.


Converting integers to strings

Sorry I missed yesterday. The family road trip ended later than expected, and I was too shot to write anything. Conversions to and from a string type … Finally, for historical reasons, an integer value may be converted to a string type. This form of conversion yields a string containing the (possibly multi-byte) UTF-8 representation of the Unicode code point with the given integer value. Values outside the range of valid Unicode code points are converted to "\uFFFD".


Converting slices to byte or rune slices

No livestream today, as I’m traveling with my family. See you next week! Conversions to and from a string type … Converting a value of a string type to a slice of bytes type yields a non-nil slice whose successive elements are the bytes of the string. []byte("hellø") // []byte{'h', 'e', 'l', 'l', '\xc3', '\xb8'} []byte("") // []byte{} bytes("hellø") // []byte{'h', 'e', 'l', 'l', '\xc3', '\xb8'} []myByte("world!") // []myByte{'w', 'o', 'r', 'l', 'd', '!


Converting rune slices to strings

Yesterday we started through the list of rules and special cases for converting to and from string types. Let’s continue… Conversions to and from a string type … Converting a slice of runes to a string type yields a string that is the concatenation of the individual rune values converted to strings. string([]rune{0x767d, 0x9d6c, 0x7fd4}) // "\u767d\u9d6c\u7fd4" == "白鵬翔" string([]rune{}) // "" string([]rune(nil)) // "" type runes []rune string(runes{0x767d, 0x9d6c, 0x7fd4}) // "\u767d\u9d6c\u7fd4" == "白鵬翔" type myRune rune string([]myRune{0x266b, 0x266c}) // "\u266b\u266c" == "♫♬" myString([]myRune{0x1f30e}) // "\U0001f30e" == "🌎" I think this one is pretty intuitive.


Conversions to and from a string type

Before I dive in to today’s spec discussion… are you enjoying this series? If so, would you do me a favor and help spread the word? Can you share a link to this message with a fellow Gopher, or on your work chat? Conversion to and from string types is a minefield of special cases in Go. So this will take at least a couple of days. Let’s dive in.