New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
io: add ReadSeekCloser interface #40962
Comments
How do we draw the line between interfaces to add to the standard library and interfaces to leave out? |
We obviously don't want to have to expose every interface combination possible in the standard library, so my first intuition is to default to no, resist establishing rules/criteria, and adopt a case-by-case approach. A strong argument in favor of this approach is that not all packages are the same. Specifically, the purpose of the In other words, adding
|
But this is not true. In go, interface equality isn’t defined by the methods of the interface, not its name. Thus anyone can declare the compound interface you outline above and it will operate identically. |
Absolutely, but that doesn't mean the ecosystem wouldn't benefit from a single declaration of the type. Otherwise, why have So the two most important factors here in my opinion are:
|
I’ve often asked myself this question, but I don’t think the answer is that the existing interface declarations in the io package represent a precedent for more interface declarations in the io package. |
I started looking at this and it does get a defined a lot. Will report back with stats but it might be worth doing. |
After removing duplicates due to rampant GitHub forking, I'm left with an interface named Read(er)?Seek(er)?Close(r)? being defined in all the modules in the list below, which seems like enough. A small number of them are not defined as Read+Seek+Close. Maybe if we'd defined io.ReadSeekCloser from the start, those would have picked a clearer name.
The full definitions are in the attached readseekclose.txt. Remember that this drops duplicates due to forks, and also duplicate definitions of ReadSeekCloser within a single module (in different packages). |
Seems worth adding to me. |
Don't see any downside. |
Based on the discussion above, this seems like a likely accept. |
Implementation should be trivial, but happy to contribute. |
@mohamedattahri Go for it. |
Research showed that this interface is defined frequently enough in real-world usage to justify its addition to the standard library. Related to golang#40962
Change https://golang.org/cl/261577 mentions this issue: |
Research showed that this interface is defined frequently enough in real-world usage to justify its addition to the standard library. Fixes golang#40962
No change in consensus, so accepted. |
@rsc @ianlancetaylor – This was my first contribution. Quick note to thank you both and congratulate the team for a super smooth process and no learning curve for any lambda Go developer using Github. Cheers. |
@mohamedattahri Thanks for implementing it. |
Background
I have several projects where I find myself needing to implement an interface that combines
io.ReadSeeker
withio.Closer
.Quick search on Github reveals that it's not an uncommon need. In some instances, the interface is implemented more than once in the same project to avoid unnecessary imports of some packages.
Description
Proposal is to simply add a new
ReadSeekCloser
interface to theio
package.Costs
Can't think of anything other than the addition to the
io
package.The text was updated successfully, but these errors were encountered: