cc @kardianos @bradfitz

ISTM, it should be called "wrap" not "unwrap" because you are wrapping it in the any type interface.

Also, I think you should return a zero T, not nil interface in the invalid case, so callers can still use a type switch to figure out what type it was supposed to be.

// Wrap the value of n in an interface for use in dynamic type switches.
// Even if n is invalid, it will still return a value that is of concrete type T.
func (n Null[T]) Wrap() (value any, valid bool) {                                                                                                                                                     
	if !n.Valid {
		var zero T
		return zero, false
	}
	return n.V, true
}

Also, I think you should return a zero T, not nil interface

I agree. In that case wouldn't it more appropriate to for the return type to be (value T, valid bool) instead of (value any, valid bool) ?

I agree. In that case wouldn't it more appropriate to for the return type to be (value T, valid bool) instead of (value any, valid bool) ?

I thought that at first too, but no because you want to be able to do

type NullWrap interface {
	Wrap() (value any, valid bool)
}

if nw, ok := val.(NullWrap); ok {
    rval, ok := nw.Wrap()
    switch rval.(type) {
    // etc.
    }
}

If the interface were generic, you couldn't do a runtime assert of nw, ok := val.(NullWrap); ok.

I don't think NullWrap needs to be defined in the sql package though. Let callers who need it define it on their end.

I don't think NullWrap needs to be defined in the sql package though. Let callers who need it define it on their end.

If the interface is not declared, it will not be documented. Having documentation for it is part of the proposal.

ISTM, it should be called "wrap" not "unwrap" because you are wrapping it in the any type interface.

I called it Unwrap because it takes one value as input and returns 2 values: one any and one bool.

I think that the NullWrap name would be unsuited for that reason.

To help understand the motivation behind the proposal, could you give some practical examples of a use-case or a problem, where one wanted to unpack some Null*Like value into a (any, bool) pair?

The current version mentions:

[before Go 1.22] the list of types was known, so it was possible to use a type switch

Note that a user could always define their own nullable types, e.g. NullIPAddr to use as a Scanner/Valuer.