On Mon, Jul 7, 2025, 8:47 AM Robert Engels <reng...@ix.netcom.com> 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 On Jul 7, 2025, at 10:43 AM, 'Keith Randall' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > > See the second paragraph in the compiler section of the go1.25 release > notes: https://tip.golang.org/doc/go1.25#compiler > The 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 >> <https://pkg.go.dev/io#Reader> 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 >> <https://go.dev/ref/spec#Variables> of type T pointed to by x. If x is nil, >> an attempt to evaluate *x will cause a run-time panic >> <https://go.dev/ref/spec#Run_time_panics>.* >> >> On Sunday, 6 July 2025 at 07:05:12 UTC+1 Kurtis Rader wrote: >> >>> On Sat, Jul 5, 2025 at 9:19 PM Ge <everg...@gmail.com> wrote: >>> >>>> Thanks Ian and Dominik for the tips. I have checked the issue 72860 and >>>> found randall77 posted a comment that >>>> I couldn't confirm from golang spec(go.dev/ref/spec): >>>> >>>> //https://github.com/golang/go/issues/72860#issuecomment-2734549770 >>>> ``` >>>> >>>> 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 > <https://groups.google.com/d/msgid/golang-nuts/61d20eb5-8102-429e-a29c-17a3da0314f3n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- > 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 > <https://groups.google.com/d/msgid/golang-nuts/7D77D6E6-277A-4014-8F4D-C034B3973526%40ix.netcom.com?utm_medium=email&utm_source=footer> > . > -- 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/CAOyqgcXhq1rodEzkoL%3DULshVaKTBFUqn%2B8aJOZhTHXmNYsvktg%40mail.gmail.com.
