4 ms·
> Nothing prevents you to call deleted(mutable) and discard the result The Go compiler generates an error when you are (silently) ignoring the return value of
by ReleaseCandidat 3y ago
> Nothing prevents you to call deleted(mutable) and discard the result
The Go compiler generates an error when you are (silently) ignoring the return value of any function.
Or, to put it in other words, every compiler which does allow to (silently) ignore the return value of a function, should not be used at all (C++ has at least `[[nodiscard]]` since 17 and C with C23 - which is "too little and too late", as always).
- deleted 3y ago[deleted]
- masklinn 3y ago> The Go compiler generates an error when you are (silently) ignoring the return value of any function. It does not. You can actually infer that from TFA listing cases as problematic which would be caught by such a compilation error, and confirming it by just compiling them: a := []int{} // compiler says nothing slices.Delete(a, 0, 0) The builtins are special cased to error if their return value is ignored (except for copy and recover). > C++ has at least `[[nodiscard]]` since 17 and C with C23 - which is "too little and too late", as always You can't even mark your own functions or types as nodiscard in Go. You need third-party tooling even just to ensure you're not unwittingly ignoring error results: f, err := os.Create("/tmp/filename") if err == nil { return } // compiler doesn't say anything even though f.Close returns error f.Close()
- ReleaseCandidat 3y agoSorry, yes, you are of course right. That's the linter which complains, not the compiler. I have to say that I don't understand the rationale of a compiler that errors on unused variables but lets the user silently ignore function return values. As a solution to explicitly ignore return values already exists in the language.