https://golang.org/doc/faq#x_in_std

Personally I'd rather encoding/csv got moved out of the standard library rather than giving it more features.

Could be a good Go 2 proposal: remove encoding/csv. 😄

The main reasons I want my additions in the stdlib are: I can slightly simplify the code if I could access encoding/csv's package internals and it's more convenient to use a stdlib package than an external package. In theory, go dep should resolve the second issue.

I'd be happy to see encoding/csv move out of the standard library. It might be a good trial run for moving more things out of std, and maybe how it works in practice to break backwards compatibility as we do so. (Do people take the code upgrade hit or stay with the deprecated stdlib version anyway? What kind of docs and tools are needed in practice? Etc.)

I'd like to see it move to an x repo. Even go4.org feels pretty dependent on one person. And moving it to x would I think help adoption/migration and help avoid unnecessary fragmentation.

Maybe @nussjustin would be interested in spearheading the fork and maintaining the package going forward? I doubt it'd require all that much ongoing maintenance, perhaps after an initial first burst of activity.

I know this is something commonly needed/wanted (last time I needed/wanted something like this was today...), but I'm not convinced that we should add this to the stdlib.

encoding/csv is a small package which a small API that can be easily extended via other packages. Adding a whole new type like the proposed field reader seems rather heavy to me, especially when the type itself doesn't really depend on encoding/csv itself, as in this case. If we decide to do this, I'd prefer a new method or two on Reader instead of a new type.

Considering this I'd be ok with having something like this outside the stdlib e.g. in an golang.org/x repo, but not really in the stdlib. At this end I agree with @ianlancetaylor and @josharian.

Speaking of @josharian ...

I'd be happy to see encoding/csv move out of the standard library.

Not just you.

It might be a good trial run for moving more things out of std, and maybe how it works in practice to break backwards compatibility as we do so.

I like the idea. If there is anything I can help with, just tell me.

Maybe @nussjustin would be interested in spearheading the fork and maintaining the package going forward? I doubt it'd require all that much ongoing maintenance, perhaps after an initial first burst of activity.

See my previous sentence :-)

I like having encoding/csv in the standard library. I'm not one of the standard library minimalists.

But this is easy to build on top of the encoding/csv in the standard library. Why put it in? Also, it's far less efficient when reading big files than the slice.

Closing the issue because there’s not enough interest in it, and it’s not hard to do this as a third party.