Here's an experience report from k8s: https://medium.com/@arschles/go-experience-report-generics-i...
They've been using a code generator as a work around: https://github.com/google/gvisor/tree/master/tools/go_generi...
It also sounds like the nesting does not escape the function itself. It always either returns error, or doesn't.
func ReadFile(path string) (string, error) {
b, err := ioutil.ReadFile(path)
s := string(b[:])
return s, err
}
How this function would be written regarding to drafts?. I am really confused.> A check returns from the enclosing function by returning the result of invoking the handler chain with the error value.
> A return statement in a handler causes the enclosing function to return immediately with the given return values. A return without values is only allowed if the enclosing function has no results or uses named results. In the latter case, the function returns with the current values of those results.
> A handler chain function takes an argument of type error and has the same result signature as the function for which it is defined.
> If the enclosing function has result parameters, it is a compile-time error if the handler chain for any check is not guaranteed to execute a return statement.
So any handler defined in ReadFile would be required to return (string, error) or not include a return at all (such that other handlers got their chance to interact with the error).
func ReadFile(path string) (string, error) {
b := check ioutil.ReadFile(path)
return string(b), nil
}The default handler will populate the last element of the return list with the error, and return.
The other elements get zeroes, if not named, or they are unchanged from how they have already been set, if named.
But these possible nested error handlers and generics will lead developers to think more than twice during writing or reading a code base. These ideas is not belong to go era but Java, C++ etc which go doesn't wanted to be like.
Someone here has mentioned that internal support of generics for slices, maps and other primitives. I think this can be the best solution for generics in go. For the error handling I think more elegant way could be found.
Please do not rush.