2 min read
Passing arguments to ... parameters
If you’ve been a reader for a while, you may recall back in April when I first talked about variadic functions. Now we’re ready to dig in a bit further to the details of how these mysterious creatures work. First we’ll see how they work “from the inside”. That is, from the perspective of someone writing a variadic function. Passing arguments to ... parameters If f is variadic with a final parameter p of type .
1 min read
Refresher on methods
In yesterday’s email, I failed to include the example included in the spec, which doesn’t make sense to include otherwise. I’ve updated the web version of the email in case you’re super curious to see what I left out. We’ve already covered these details, but they’re logically mentioned again in the section about function calls, so we’ll cover them here: Calls … A method call x.m() is valid if the method set of (the type of) x contains m and the argument list can be assigned to the parameter list of m.
3 min read
Special case: Multi-value arguments to functions
You may recall that when we started the section on function calls, we were told about a “special case”… well here it is! Calls … As a special case, if the return values of a function or method g are equal in number and individually assignable to the parameters of another function or method f, then the call f(g(parameters_of_g)) will invoke f after binding the return values of g to the parameters of f in order.
2 min read
nil functions
Calls … Calling a nil function value causes a run-time panic. So, calling a nil function causes a panic. Sensible enough. But when would you ever run across a nil function? Let’s look at some examples. This is probably the most obvious example, and perhaps one that popped to your mind: var fn func(int) // fn is of type func(int), but uninitialized, so nil fn(3) // run-time panic But let’s consider another example, which can be a bit more confusing.
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
Evaluation of function parameters
Calls If f denotes a generic function, it must be instantiated before it can be called or used as a function value. We’ve seen this rule applied to methods and other types. It should be standard by now, so I won’t dwell on it. In a function call, the function value and arguments are evaluated in the usual order. After they are evaluated, the parameters of the call are passed by value to the function and the called function begins execution.
2 min read
The type of a function call expression
Calls … The type of the expression is the result type of F. A method invocation is similar but the method itself is specified as a selector upon a value of the receiver type for the method. math.Atan2(x, y) // function call var pt *Point pt.Scale(3.5) // method call with receiver pt We recently talked about method calls already, so we don’t need to expand much more on those.
2 min read
Calls
Calling all gophers! It’s time to talk about… Calls! Calls Given an expression f with a core type F of function type, f(a1, a2, … an) calls f with arguments a1, a2, … an. This basic syntax is common to many languages, so should not feel at all strange if you have any programming experience at all. So let’s dive right into the nitty-gritty details… … Except for one special case, arguments must be single-valued expressions assignable to the parameter types of F and are evaluated before the function is called.
3 min read
Type assertion values
By now you’ve guessed there was no live stream today. Illess has been hitting my family hard. I’ll try to pick it up again after the new year. Type assertions … If the type assertion holds, the value of the expression is the value stored in x and its type is T. If the type assertion is false, a run-time panic occurs. In other words, even though the dynamic type of x is known only at run time, the type of x.
1 min read
Type assertions of interface types
Type assertions … If T is an interface type, x.(T) asserts that the dynamic type of x implements the interface T. This simple sentence has some pretty profound implications. Let’s start with a simple example: type Fooer interface { Foo() } type thing int func (thing) Foo() {} var x interface{} = thing(3) x.(Fooer) // Valid, the result is an interface of type Fooer This can be very useful to convert from the empty interface (aka interface{} or any) to a more specific interface, as in the above example.
2 min read
Type assertions of non-interface types
Yesterday we started on type assertions. Today we’ll look at some of the specific details, as they relate to type assertions to non-interface types. Tomorrow we’ll look at interface types. Type assertions … More precisely, if T is not an interface type, x.(T) asserts that the dynamic type of x is identical to the type T. Recall that variables of interface types contain a dynamic type, which represents the type that satisfies the interface:
1 min read
Type assertions
Type assertions For an expression x of interface type, but not a type parameter, and a type T, the primary expression x.(T) asserts that x is not nil and that the value stored in x is of type T. The notation x.(T) is called a type assertion. For now, let’s look at some examples of type assertions that hold, and that don’t. In the next day or two, we’ll look at more details from the spec.