Go has some weird syntactic sugar including where a method invocation is rewritten by the compiler to pass in a value or a pointer depending on what the callee wants(!?!). And yet Go code is still littered with: if err != nil { ... rather than some simple, compile-time validated sugar to pass the error value up the call chain. Yes, I've read the justification documents. No, they still don't make a very convincing arg…
This is only method receivers, not for arguments. Essentially the way of invoking a method on a pointer receiver (like '->' in C/C++) isn't any different than invoking it on a value receiver (like '.' in C/C++). But you can't pass 'pointer to int' to a method where 'int' is expected.
> some simple, compile-time validated sugar to pass the error value up the call chain
This bothers me a bit, too. Sometimes I was able to work around it in a creative way. Take http handlers as an example:
func standardHandler(w http.ResponseWriter, r *http.Request) {
// errors may occur here...
}
type naiveHandler(w http.ResponseWriter, r *http.Request) error
func handleErrors(fn naiveHandler) {
return func(w http.ResponseWriter, r *http.Request) {
if fn(w, r) != nil {
// handle errors
}
}
}
http.HandleFunc("/", handleErrors(handler1))
http.HandleFunc("/", handleErrors(handler2))
// ...
RETURN_ERR_UNLESS_NIL(/* Go expression returning only error */)