1 min read
Blank operands
Don’t you just love the blank identifier? I sure do! And it the blank identifier can be an operand, too! But with a limitation: Operands … The blank identifier may appear as an operand only on the left-hand side of an assignment statement. So this means that _ = 3 is valid, but var x = _ Is not. And I hope it’s pretty obvious why that is the case. What would the value of x be in such an example?
1 min read
Generic functions as operands
Operands … An operand name denoting a generic function may be followed by a list of type arguments; the resulting operand is an instantiated function. So first off, recall that an operand may be a function literal: var x = func() { /* ... */ } Or a variable that represents a function: var F = func() { /* ... */ } var f = F // <--- `F` is a variable that represents a function Or another expression that evaluates to a function:
2 min read
Operands
I’ll be live coding again today! I hope you can join me! I’ll be continuing where I left off, working on a new feature for my open-source CouchDB SDK, https://kivik.io/. Join me to see how many mistakes a senior Go dev makes while coding. To kick off our dissection of expressions, we’ll look at the term “operand”. You may recall from your studies of algebra that an operand is the “object upon which an operator acts.
1 min read
Expressions
There are a number of terms that get thrown around, often semi-interchangeably by the less initiated (such as myself). “Declaration”, “definition”, “statement”, … and today’s topic “expressions”, just to name a few. But, at least within the context of the Go spec, most such terms have very specific meanings. Expressions An expression specifies the computation of a value by applying operators and functions to operands. So: type foo int and var foo int are not an expressions.
2 min read
Type parameters in method definitions
Yesterday we saw that when a method is defined on a generic type, the receiver must include type parameters. Now for all the relevant details: Method declarations … … Syntactically, this type parameter declaration looks like an instantiation of the receiver base type: the type arguments must be identifiers denoting the type parameters being declared, one for each type parameter of the receiver base type. The type parameter names do not need to match their corresponding parameter names in the receiver base type definition, and all non-blank parameter names must be unique in the receiver parameter section and the method signature.
2 min read
Methods on generic types
Ready to dive back into generics, this time with regard to methods? Great, ‘cause here we go! Method declarations … If the receiver base type is a generic type, the receiver specification must declare corresponding type parameters for the method to use. Okay. Before we continue, let’s make sure we all know exactly what we’re talking about. What does it mean for a receiver base type to be a generic type?
2 min read
Uniqueness of methods
Oops! Yesterday I live-streamed… to the wrong link! If you followed the link I shared yesterday, you were probably confused. But the good news is, you can still catch the replay. Method declarations … For a base type, the non-blank names of methods bound to it must be unique. If the base type is a struct type, the non-blank method and field names must be distinct. These uniqueness rules are quite predictible!
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
Receiver uniqueness
Today I’ll be love coding again. I hope you can join me! I’ll be continuing where I left off, working on the backlog for my open-source CouchDB SDK, https://kivik.io/. Join me to see how many mistakes a senior Go dev makes while coding. Method declarations … A non-blank receiver identifier must be unique in the method signature. If the receiver’s value is not referenced inside the body of the method, its identifier may be omitted in the declaration.
1 min read
Method within selectors
Method declarations … The method is said to be bound to its receiver base type and the method name is visible only within selectors for type T or *T. This short sentence is a bit tricky to parse, because it relies on some as-yet unfamilar concepts. But it’s really pretty straight forward once those concepts are understood. A selector expression looks something like foo.bar. So given the following type and method:
2 min read
On Go's verbose error handling
I’m taking a break from the Go spec for a day, to talk about some code I just found in a codebase I’m working on, which I think says some interesting things about the argument that Go’s error handling is too verbose. When I shared this code on a Slack community, someone asked for an email-lengthed explanation, so here it is! Without further ado, here’s the code I ran across (edited slightly to be more general):
2 min read
Limitations on methods, part 3
This is part 3 of 3 of a mini-series on method limitations. If you missed the earlier installations, here are links to part 1 and part 2. Method declarations … A receiver base type cannot be a pointer or interface type and it must be defined in the same package as the method. And now for the conclusion: A receiver base type must be defined in the same package as the method.