3 ms·
I'd be really happy with that! Building the functionality of errcheck[1] and ineffassign[2] into the compiler — or at the very least, into govet — would go a lo
by cytzol 5y ago
I'd be really happy with that! Building the functionality of errcheck[1] and ineffassign[2] into the compiler — or at the very least, into govet — would go a long way to allay my worries with Go.
I think the reason they don't do this is that it's a slight (albeit a very tiny one) against Go's philosophy of errors being values, just like any other. While the `error` type is standard and used throughout Go source code, it still just has a simple three-line definition[3] and is not treated as a special case anywhere else; there is nothing stopping you from returning your own error type if you wish. A third-party linter could simply check for the `error` type specifically, but the first-party tools should not, and there's nothing like Rust's `#[must_use]` attribute that could be used instead. I respect Go's philosophy, but I feel like pragmatism must win in this case.
[1]: https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck
[2]: https://github.com/gordonklaus/ineffassign https://github.com/gordonklaus/ineffassign
[3]: https://pkg.go.dev/builtin#error https://pkg.go.dev/builtin#error
- geoka9 5y agoThere's a proposal for the Go 2 draft that addresses this: https://github.com/golang/go/issues/20803 https://github.com/golang/go/issues/20803 https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md https://go.googlesource.com/proposal/+/master/design/go2draf...