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.
1 min read
Limitations on methods, part 2
Continuining from yesterday, when we started disecting this section of the spec: 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. Today we’re tackling the second limitation: A receiver base type cannot be an interface. At first this might seem a bit counter-intuitive… aren’t interfaces all about methods? Well, yes, but in the other directions.
1 min read
Limitations on methods
Today I’ll be love coding again. I hope you can join me! I’ll be working on the backlog for my open-source CouchDB SDK, https://kivik.io/ to add a long-missing feature. Join me to see how many mistakes a senior Go dev makes while coding. 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. This tiny sentence has three distinct cases to consider.
2 min read
Method receiver base types
There’s a lot to unpack about method receiver types, so we’ll do it over two days. Method declarations … The receiver is specified via an extra parameter section preceding the method name. That parameter section must declare a single non-variadic parameter, the receiver. This bit is fairly straight forward. The receiver is specified in an extra parameter section preceeding the method name: func (reciever ReceiverType) MethodName(/* 0 or more regular arguments */) { /* .
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.
2 min read
Method declarations
Now that we’ve covered function declarations, let’s discuss the more nuanced topic of method declarations, which can be thought of as special case of of function declarations. Method declarations A method is a function with a receiver. A method declaration binds an identifier, the method name, to a method, and associates the method with the receiver’s base type. MethodDecl = "func" Receiver MethodName Signature [ FunctionBody ] . Receiver = Parameters .
1 min read
Empty function declarations
Function declarations … A function declaration without type parameters may omit the body. Such a declaration provides the signature for a function implemented outside Go, such as an assembly routine. func flushICache(begin, end uintptr) // implemented externally This is something I have never used. Most developers probably never will. Although I’ve certainly seen it a few times, particularly while browsing the standard library source code, so it’s good to be aware of it, so you aren’t stuck scratching your head when you see it.
1 min read
Generic function declarations
Function declarations … If the function declaration specifies type parameters, the function name denotes a generic function. A generic function must be instantiated before it can be called or used as a value. func min[T ~int|~float64](x, y T) T { if x < y { return x } return y } We’ve mentioned instantiation before, but it will be covered in depth later. For now, it’s enough to show an example of what the spec means can’t be done without instantiating a generic function:
2 min read
Function declarations
No livestream today. My family is on vacation this week. I’ll be livestreaming again next week! Function declarations A function declaration binds an identifier, the function name, to a function. FunctionDecl = "func" FunctionName [ TypeParameters ] Signature [ FunctionBody ] . FunctionName = identifier . FunctionBody = Block . Nothing surprising here… So let’s move on to the first interesting rule: If the function’s signature declares result parameters, the function body’s statement list must end in a terminating statement.