1 min read
Collapsing like function parameters
Yesterday we learned that we may omit function parameter and result names in a function type definition. But this poses a small limitation: Function types … If [the name is] absent, each type stands for one item of that type. What does that mean, exactly? Well, when using named parameters and results, we have the option to omit the type for subesquent arguments of the same type. Here’s an example to make it more clear;
2 min read
Naming function parameters and results
Function types … Within a list of parameters or results, the names (IdentifierList) must either all be present or all be absent. If present, each name stands for one item (parameter or result) of the specified type and all non-blank names in the signature must be unique. There are several things to unpack here. Let’s start with the most intuitive part: The names of function parameters and results must be unique.
1 min read
Function types
Go has first-class functions. That is to say, functions are treated as any other data type, and can be passed around as arguments, used as struct field types, etc. Function types A function type denotes the set of all functions with the same parameter and result types. The value of an uninitialized variable of function type is nil. FunctionType = "func" Signature . Signature = Parameters [ Result ] . Result = Parameters | Type .
2 min read
Pointers to interfaces
As I mentioned last week, a pointer in Go may have any base type. This includes interfaces. type MyInterface interface { DoStuff() } var x *MyInterface var y *interface{} var z ****interface{ Foo() } Now while these are all valid, they are rarely useful. And this often trips people up. As a rule: Never use a pointer to an interface. There is only one exception of which I am aware. And it’s so unusual, that you can generally just adhere to the above rule.
2 min read
nil pointers
Yesterday we learned about pointers. But beyond what the spec says, there are a few notes worth calling out. To start with, as mentioned in the spec, the zero value for a pointer is nil. But it’s still a typed nil value, as we can see by using the %T printf argument, which displays the variables type. Expanding on yesterday’s example: var x int var y *int var z **int // Prints: 0 <nil> <nil> <nil> fmt.
1 min read
Pointer types
After the long discussion of the details and nuances of struct types, we have a simple topic: Pointers! Well, maybe it’s not that simple. There are a lot of subtleties that go into the proper use of pointers. But from a specification standpoint, it’s simple. This is the entirety of the section: Pointer types A pointer type denotes the set of all pointers to variables of a given type, called the base type of the pointer.
2 min read
Recursive struct types
Finally, after more than a week, we’re at the end of our discussion of Go’s struct types. You may recall that recursion is not permitted within array types. We have a similar, though not identical, restriction for structs: Struct types … A struct type T may not contain a field of type T, or of a type containing T as a component, directly or indirectly, if those containing types are only array or struct types.
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
Empty structs
We finally we have enough knowledge for the EBNF format not to seem completely foreign, so let’s jump back and take a look at that, with the examples provided in the spec… Struct types … StructType = "struct" "{" { FieldDecl ";" } "}" . FieldDecl = (IdentifierList Type | EmbeddedField) [ Tag ] . EmbeddedField = [ "*" ] TypeName [ TypeArgs ] . Tag = string_lit . // An empty struct.
2 min read
Struct tags
Struct types … A field declaration may be followed by an optional string literal tag, which becomes an attribute for all the fields in the corresponding field declaration. An empty tag string is equivalent to an absent tag. The tags are made visible through a reflection interface and take part in type identity for structs but are otherwise ignored. struct { x, y float64 "" // an empty tag string is like an absent tag name string "any string is permitted as a tag" _ [4]byte "ceci n'est pas un champ de structure" } // A struct corresponding to a TimeStamp protocol buffer.
2 min read
Struct method promotion
Yesterday we saw an example of struct field promotion. But methods (which we haven’t really discussed yet) can also be promoted. Struct types … Given a struct type S and a named type T, promoted methods are included in the method set of the struct as follows: If S contains an embedded field T, the method sets of S and *S both include promoted methods with receiver T. The method set of *S also includes promoted methods with receiver *T.
2 min read
Struct field promotion
Yesterday we learned that structs can have embedded fields. Although we didn’t really learn about any of the special powers this gives us. Today we’ll have a look at those powers. One advantage to using an embedded type is that the implicit field name (the one derrived from the type, Person, in our example) can be omitted. This is the result of “promotion”. For example: var e Employee e.Name = "Bob" // equivalent to e.