1 min read
Type declarations
We’ve already talked about the different types availabe in Go, but now we’ll see how to declare them… just in case it wasn’t already obvious. Type declarations A type declaration binds an identifier, the type name, to a type. Type declarations come in two forms: alias declarations and type definitions. TypeDecl = "type" ( TypeSpec | "(" { TypeSpec ";" } ")" ) . TypeSpec = AliasDecl | TypeDef . We’ll talk about these two different forms in the coming days.
2 min read
Iota, continued
No live stream today. My office/recording studio is being painted. I’ll be back next week with more linter building! One last detail on iota… Iota … By definition, multiple uses of iota in the same ConstSpec all have the same value: const ( bit0, mask0 = 1 << iota, 1<<iota - 1 // bit0 == 1, mask0 == 0 (iota == 0) bit1, mask1 // bit1 == 2, mask1 == 1 (iota == 1) _, _ // (iota == 2, unused) bit3, mask3 // bit3 == 8, mask3 == 7 (iota == 3) ) This last example exploits the [implicit repetition](https://go.
2 min read
Iota
You may recall from yesterday that you can omit the constant expression for all but the first ConstantSpec in a parenthesized constant declaration, but that it wasn’t very useful by itself. Enter iota… Iota Within a constant declaration, the predeclared identifier iota represents successive untyped integer constants. Its value is the index of the respective ConstSpec in that constant declaration, starting at zero. It can be used to construct a set of related constants:
2 min read
Omitting constant expressions
Constant declarations … Within a parenthesized const declaration list the expression list may be omitted from any but the first ConstSpec. Such an empty list is equivalent to the textual substitution of the first preceding non-empty expression list and its type if any. Omitting the list of expressions is therefore equivalent to repeating the previous list. The number of identifiers must be equal to the number of expressions in the previous list.
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
Are you maintaining dead code?
I’m taking a break from the Go spec today to talk about a new tool I just discovered, that saved me a bunch of work. One of the clients I’m working with has a rather old codebase, filled with a bunch of retired features. It was a laborious task to go through all the thousands of files in the project to see which functions and types were no longer being used.
2 min read
Constant types
Long-time readers may recall that constants may be typed or untyped. Today we expore the details of how such constants are declared. Constant declarations … If the type is present, all constants take the type specified, and the expressions must be assignable to that type, which must not be a type parameter. If the type is omitted, the constants take the individual types of the corresponding expressions. If the expression values are untyped constants, the declared constants remain untyped and the constant identifiers denote the constant values.
2 min read
Constant declarations
I’m live streaming again! You’ll probably read this after the fact, but if not, come join me live, or catch the replay! I’ll be building a real-world linter from scratch, picking up from the tutorial I did 2 weeks ago. If you’ve been reading me for a while, you’ll recall we’ve already talked about constants in Go. However, we’ve done it in a slightly more abstract sense; constant literals, and they’re types.
1 min read
Uniqueness of identifiers
Uniqueness of identifiers Given a set of identifiers, an identifier is called unique if it is different from every other in the set. Two identifiers are different if they are spelled differently, or if they appear in different packages and are not exported. Otherwise, they are the same. This is pretty simple stuff, but it’s obviously worth being explicit. foo and bar are obviously different identifiers. Further, a in package foo, and a in package bar are different identifiers, because although they are spelled the same, they are not exported, and are in different packages.
2 min read
Exported identifiers
Exported identifiers An identifier may be exported to permit access to it from another package. An identifier is exported if both: the first character of the identifier’s name is a Unicode uppercase letter (Unicode character category Lu); and the identifier is declared in the package block or it is a field name or method name. All other identifiers are not exported. The main surprising thing to take out of this section is that an exported field or method may be accessible outside of the package even if the type it’s defined on is not!
1 min read
Predeclared identifiers
Predeclared identifiers The following identifiers are implicitly declared in the universe block: Types: any bool byte comparable complex64 complex128 error float32 float64 int int8 int16 int32 int64 rune string uint uint8 uint16 uint32 uint64 uintptr Constants: true false iota Zero value: nil Functions: append cap close complex copy delete imag len make new panic print println real recover Perhaps confusingly, any of these can be shadowed. That is, you can bind these names to your own variables, constants, functions, etc.
1 min read
Blank identifier
Blank identifier The blank identifier is represented by the underscore character _. It serves as an anonymous placeholder instead of a regular (non-blank) identifier and has special meaning in declarations, as an operand, and in assignment statements. Ah, the blank identifier! We’ve talked about it in a few contexts already. Namely, struct field names, as well as binding variables. But it can be used in many places… Including a few surprising places, where it never serves a purpose.