Re-consider interface-based approach for R[T]

[kdungs]

I.e.

type R[T any] interface {
  Unwrap() (T, error)
  Or(T) T
}

with two (unexported) implementations for error / value

type rErr[T any] struct {
  err error
}

type rVal[T any] struct {
  v T
}

The only way for calling code to construct them would be through Of, OfErr, or Wrap. For Wrap we'd need to handle the case where the user provides both an error and a value. Instead of panicking we should probably just return rErr because that's what all the current implementations of the free functions do implicitly, as well. (Since they unwrap and check for err != nil, first).

[kdungs]

No shortcuts! If an error happens early on, all computations still happen in the form of forwarding the error. With the current implementation this also means constructing a few default values on the way.

Using the interface-based approach, we'd still not get shortcuts, but at least we wouldn't construct a bunch of useless default values along the way 🤔 .

[kdungs]

Using the interface-based approach, we'd still not get shortcuts, but at least we wouldn't construct a bunch of useless default values along the way 🤔 .

This actually wouldn't happen automatically. If we just switched the current implementation of R[T] for one based on an interface, the free functions would still be based on Unwrap and unnecessary default values would be constructed along the way. Instead, we'd probably have to match on type internally...