data, _ := os.ReadFile(path)
In a language like Rust, if the return type is `Result<MyDataType, MyErrorType>`, the caller cannot access the `MyDataType` without using some code that acknowledges there might be an error (match, if let, unwrap etc.). It literally won't compile.
I think you can make the same argument here - rust provides unwrap and if you don’t know go, that’s just how you get the value out of the Result Type.
a, err := f()
// whether you forgot to handle the `err` or not,
// the `a` carries a zero value, or some other value.
Or you could return pointers and use `nil` in the error case. Bonus is that it'll then panic if you try to use it without checking the error.
(Yes, I know, it makes everything else a faff and is a silly idea.)
> But if you don't know Go, it's just an underscore.
And if you don't know rust, .unwrap is just a getter method.
But I'm just explaining the argument as I understand it to the commenter who asked. I'm not saying it is right. They have tradeoffs and perhaps you prefer Go's tradeoffs.
What if it’s a function that returns the coordinates of a vector and you don’t care about the y coordinate?
x, _ :=
func ParseStringToBase10i32AndIDoNotCare(s string) {
i, _ := strconv.ParseInt(s, 10, 32)
return i
}
Ignoring an output data value or set is just fine. Don't always need the key and value of a map. Nor a y axes in vector<x,y,z> math.
(Or in your commit hook. If you want to develop without worrying about such things, and then clean it up before checkin, that's a development approach that go is perfectly fine with.)
And the more I work with Go, the less I understand why warnings were not added to the compiler. Essentially instead of having them in the compiler itself, one needs to run a tool, which will have much smaller user base.
But anyway, in Go, it's sometimes fine to have both non-nil error and a result, e.g. the notorious EOF error.
file.Close()