Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
proposal: errors: generalize As to all types #33473
The errors proposal introduces a new paradigm for inspecting wrapped errors.
I love this new paradigm and I think it should be extended to any interface. The one that immediately comes to my mind that would benefit is http.ResponseWrapper.
There are 2 "easy" ways to address this: a wrapping type can either expose them directly, and if the underlying type doesn't implement them, the method becomes a no-op; or the wrapping type can expose the original ResponseWriter, but this may leak functionality.
This nested wrapping looks very similar to the errors problem. But what if the wrapper was written like this?
Some unknowns about this proposal:
I think the real power in the
This is tedious and not future proof. However, a generalized method depends on reflection.
it's a stand-in for an http.HandlerFunc. A common use case is I want to log the request time for an http Handler. I would usually do something like:
thanks for your time.
I made the same proposal in my feeedback on the xerrors package: https://gist.github.com/carlmjohnson/d06cd8d10e0aef65f565a55cc57cd986
I think @rsc is correct that we can revisit the question of generalizing this after xerrors.Is/As has been in wider use.
Based on the discussion above, I think we should probably decline this proposal and encourage filing a new proposal in a year or two based on our experience with errors.As. Putting this proposal on hold for a year or two would not make sense because the right thing to do in a year or two is likely to differ in the details - better to write a new proposal.