It seems I clearly don’t understand it - based on the example in the documentation for the 1.25 compiler changes - why would this gave to panic? You can call methods on nil pointers - so this call is valid - it all depends on what the method does.
Eg in this case f.Name() could return a default if f is nil.
So what is the fix here referring to? Maybe it is just an example that requires the semantics of these api calls? On Jul 7, 2025, at 10:53 AM, Ian Lance Taylor <i...@golang.org> wrote:
This change seems wrong just based on the io.Reader returns of valid bytes and an error. An error doesn’t always mean the other return values are invalid - it is decided by the api method.
I think you are misunderstanding the actual change, which is about how nil dereference checks are handled. Previously they were moved later than they should have been.
Ian
See the second paragraph in the compiler section of the go1.25 release notes: https://tip.golang.org/doc/go1.25#compilerThe example looks strangely familiar... On Sunday, July 6, 2025 at 1:18:20 AM UTC-7 Brian Candler wrote:
The main example which springs to mind is io.Reader.Read which may return a non-zero number of read bytes *and* and error from the same call. Because this is so unusual, it is carefully emphasised in the docs:Callers should always process the n > 0 bytes returned before considering the error err. Doing so correctly handles I/O errors that happen after reading some bytes and also both of the allowed EOF behaviors. Anyway: the point here is that if a function returns (ptr, err) then in the case err = nil it will conventionally guarantee that ptr is valid, so the caller doesn't need to check ptr != nil before dereferencing it. But if err != nil, no such guarantee is implied, and it's highly unlikely that you could safely deference ptr. That convention is not in the spec, but dereferencing a nil pointer causing a panic is:
the pointer indirection *x denotes the variable of type T pointed to by x. If x is nil, an attempt to evaluate *x will cause a run-time panic.
On Sunday, 6 July 2025 at 07:05:12 UTC+1 Kurtis Rader wrote:
Thanks Ian and Dominik for the tips. I have checked the issue 72860 and found randall77 posted a comment that
``` Where f returns a pointer and an error. f expects its callers to only use the ptr result if the error is nil. And in particular, f returns a nil pointer whenever it returns a non-nil error. This code is incorrect, in that it dereferences the ptr result before checking the error. The Go spec says that it should nil pointer panic if f returns a nil pointer and non-nil error. ```
I did a search in whole spec and did't find any descriptions about it. From my understanding, `v, err := f()` is like `v1, v2 := f()` from compiler's view, checking error is user code's business logic and couldn't be assumed by compiler. If it's defined in spec, what about variants like `a, b, err := f()` or `a, b, err1, err2 := f()`？
No, it is not defined in the spec. For the very reasons you mention (and probably others). But I would argue that commonsense suggests that unless a function explicitly says a returned non-error pointer is useful (i.e., non-nil) when an error is returned you should assume that pointer is likely to be nil if an error is indicated. Ideally this would be explicit in the documentation of every function that returns an error and non-error pointer. However, in the absence of the documentation stating that the non-error pointer value is useful if an error is indicated it seems reasonable to assume that pointer is not useful; even if it isn't nil. Even a non-pointer return value is unlikely to be meaningful if an error was indicated unless explicitly documented. If the called function returns the "zero value" when it also returns an error indicator what does it mean to ignore the error and use the "zero value"? That's obviously context dependent but it is unlikely, in my experience, to ignore the error and use the returned "zero value". Kurtis Rader Caretaker of the exceptional canines Junior and Hank
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/61d20eb5-8102-429e-a29c-17a3da0314f3n%40googlegroups.com.
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/7D77D6E6-277A-4014-8F4D-C034B3973526%40ix.netcom.com.
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/92C78124-EAF8-4E6C-B239-D888061F634A%40ix.netcom.com.
|
