proposal: errors: Is(err, target) should allow err to decide even when target is nil

[pjebs]

Currently Is looks like this:

func Is(err, target error) bool {
	if target == nil {
		return err == target     // <-------------
	}
	isComparable := reflectlite.TypeOf(target).Comparable()
	for {
		if isComparable && err == target {
			return true
		}
		if x, ok := err.(interface{ Is(error) bool }); ok && x.Is(target) {
			return true
		}
		if err = Unwrap(err); err == nil {
			return false
		}
	}
}

See:
https://golang.org/src/errors/wrap.go?s=1170:1201#L29 and also
https://github.com/golang/xerrors/blob/master/wrap.go#L50

[pjebs]

See: https://github.com/rocketlaunchr/dataframe-go/blob/master/error_collection.go#L11
Sometimes error objects are designed as containers of/for multiple errors.

type ErrorCollection struct {
	errors []error
}

The proposal suggests that errors.Is(err, target) should be adjusted such that when target is nil and err is for example an ErrorCollection, the ErrorCollection should be able to decide whether it is nil or not via implementing Is(err error) bool {.
See: https://github.com/rocketlaunchr/dataframe-go/blob/master/error_collection.go#L62

It is feasible that when the error collection holds no errors, it would like to allow the user to write:

	ec := NewErrorCollection()
	isNil := errors.Is(ec, nil) 

where isNil is set to true (since ec currently holds no errors).

But due to the implementation of errors.Is, this will return false.

[pjebs]

The documetation currently states:

An error is considered to match a target if it is equal to that target or if
it implements a method Is(error) bool such that Is(target) returns true.

Due to the phrasing, the current proposal is still consistent with the documentation and arguably should not be deemed to breach Go1 backward compatibility guarantees (as it could be interpreted as a bug).

[ianlancetaylor]

The predeclared type error is an interface type. It is only nil if it is completely unset. Giving a type like ErrorCollection a way to decide whether it is nil is going to run straight into https://golang.org/doc/faq#nil_error. I think it would be a mistake to make the handling of a nil interface any more complex.

[rsc]

Absolutely. It would be very unfortunate if we permitted err != nil && errors.Is(err, nil) == true.

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[urandom2]

this feels like a duplicate of #40673? (or maybe #40674)

[kortschak]

The essence of this behaviour can be achieved by defining an empty error type/value that the error collection can compare itself to in the Is call. Alternatively (and probably preferably), the error collection can be created with a NewErrorCollection(errs []error) error function that returns nil if len(errs) == 0 at the end of the region that generates the collection of errors.

[rsc]

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

[rsc]

No change in consensus, so declined.
— rsc for the proposal review group