Nope. This mostly becomes a problem if you like to be DRY and try to replace generics (type T) kind of functionality with interfaces. For e.g., I have a method, which does the classic, lookup from cache first before hitting the actual db. In C#, you can use
public T Get<T>(int id, string cacheKey) {
}
When I consume it and say Get for User object, I expect an User object as I already know it's type.
In Go, you have to return an interface (and ideally an error)
Here would be the equivalent,
v, err := s.Get(id int, cacheKey string)
if err != nil {
//Handle error here
}
if v == nil || v.(*models.User) == nil {
return nil, http.StatusNotFound
}
Its a bit more code, but on the flip side, it gets you thinking as a client of all the things that can go wrong with your code
This is called a type assertion in Go. Whenever you ask for something as an interface but want to use the type's own method, you have to make a type assertion.
interface Fooer {
func Foo()
}
type Bar struct {}
func (s Bar) Foo() {}
func (s Bar) Baz() {}
func DoFoo(f Fooer) {
f.Foo() // fine
// f.Baz() compile error
f.(Bar).Baz() // fine
}
Isn't the entire point of an interface to communicate the behaviour expected by the function though?
If you want a Bar specifically (as the DoFoo code does above), it should take a Bar as an argument.
If you want to accept any struct that satisfies Fooer, add all the methods to Fooer that you need them to satisfy...
Doing otherwise is just subverting the type system and you might as well use a blank interface and effectively have no type checking on your input - if you require a Fooer and then typecast someone might pass a Fooer and get a nasty surprise when it doesn't work.
In Go, you have to return an interface (and ideally an error)
Here would be the equivalent,
Its a bit more code, but on the flip side, it gets you thinking as a client of all the things that can go wrong with your code