These operations would help but they're not unique to errors, even though they most often arise in that context.
Since this proposal relies on some form of generics to implement As, why not make the interface and both operations generic so we can Is or As a wrapped io.Reader just as easily?
Right, but it would be errors.As(wrappedReader, io.ReaderAt)
I think one of us is misunderstanding the other; my point is that As(wrappedReader, io.ReaderAt) doesn't seem to be useful under any circumstance I can see, so this doesn't appear to be an argument in favor of making the operation generic.
When do you see an unwrapping As function as being useful for non-errors?
When wrapping a possibly already wrapped reader you could see if it was already buffered and choose to use the minimum buffering needed to implement your wrapper's functionality, knowing that the underlying buffering will take care of the rest. It would also be useful for debugging since you could print out the entirety of the nesting (that wouldn't use As or Is, just the interface, though).
I'm sure there are use-cases for http.ResponseWriter as well since it can have lots of extra methods which makes it very hard to wrap as it is now.
I think these operations actually are fairly unique to errors. Errors are different from most other interface values in that you almost always need to covert them to some other type in order to use them for any purpose other than printing. An
io.Readeris useful as it is.Optional ancillary methods such as
io.ReaderAtare an exception. I'm guessing you might be suggesting this as a way to address the case where you want to wrap something with optional methods like these? I don't thinkIsandAsoffer much here. If the wrapper implementsUnwrap, thenAs(wrappedReader, io.ReaderAt)will return the underlying reader without whatever additional functionality is provided by the wrapper type.