Reading the same code I also cringed, but for a different reason: the validity of `paths` is tied to the validity of `err`; you should never look at at `paths` without first checking `err`. We can solve this much better using sum types (also known as discriminate unions):
// Pseudo Go:
maybe_paths := filepath.Glob(dir + "/*.png")
case maybe_paths of {
Some paths: {
// Do things with paths
}
None: {
// Handle error case
}
}
This makes it impossible to use `paths` if `Glob` returns an error, as `paths` won't be in scope!
Furthermore, not having sum types forces us to include a distinguish value `null` for reference (pointer) types, as a way to communicate "no value". This is bad as now we cannot distinguish references that should never be `null` from those than can be `null`.
You can distinguish between nulls which are errors and nulls that are just the actual return value. That is what err is for.
The entire reason Go has multiple return values for functions (such as paths and err in this case) is to avoid having to encode errors in the "real" function result.
Now I agree, that this is less nice as say pattern matching and real sum types, but if you know how to appreciate those just switch to a functional language!
> The entire reason Go has multiple return values for functions (such as paths and err in this case) is to avoid having to encode errors in the "real" function result.
That's nonsense, MRVs are tuples (conceptually, Go implemented them with special syntax because... well, it's Go so it could not go with the general principle now could it?), so Go very specifically encodes errors in the function result.
And using a sum type would encode the error in the type, not in the result itself.
This kind of fussy type system is at odds with Go's design goals. It would make the language more abstracted from the underlying machine for little gain. I can't think of an instance of the issue you describe causing problems in real Go code.
> This kind of fussy type system is at odds with Go's design goals.
There is nothing fussy about it, and the only way in which it's at odds with Go's design goals is that Go's design goals include things like "fuck you, only core types get to be generic", "that these mistakes were resolved 20 years ago does not mean we're not going to re-introduce them" and "if we give it a different name it's not the same thing, nah nah nah".
Furthermore, not having sum types forces us to include a distinguish value `null` for reference (pointer) types, as a way to communicate "no value". This is bad as now we cannot distinguish references that should never be `null` from those than can be `null`.