/cc @bradfitz @ALTree

Or copy database/sql? https://golang.org/pkg/database/sql/#Row.Scan

/cc @kardianos

The difference between encoding/csv and database/sql is that sql will return always return a rectangular result while csv may have jagged results. Another difference is that sql will do type conversions while csv only handles strings.

I think an API like this makes sense. In this API proposal, can s be written to even if a new slice is allocated (is this written to field by field or buffered internally?

The other option I could see is adding a csv Reader option that reuses the same buffer for each call to Read (ReadAll would be unaffected).

The current implementation of encoding/csv knows exactly how many fields a record has when allocating the slice, so there would be no need to modify s when it is to small.

Internally this would be implemented like this:

if len(s) >= fieldsCount {
    record = s[:fieldsCount]
} else {
   record = make([]ſtring, fieldsCount)
}

The comment for ReadInto currently states:

// If the record has more than len(s) fields, a new slice will be allocated
// instead and s will not be modified.

Although probably nice, this is a somewhat big restriction for future changes.

I also thought about adding a new field to the Reader, but I decided against it based on personal preference, even if the current proposal adds another new method. Considering ReadAll, adding a new field would need to make sure that ReadAll doesn't use it by making a copy after each call to Read or even preventing the reuse (this would avoid an extra copy).

Or we could add a bool field to csv.Reader, like Reader.ReuseRecord' that causes Reader.Read` to always use the same slice.

Edit: I can't read. @nussjustin addressed this above. But I still think if we're going to add API for a performance case, it should be less high profile than a new method.

I also thought about adding a new field to the Reader, but I decided against it based on preference, even if the current proposal adds another new method. Considering ReadAll, adding a new field would need to make sure that ReadAll doesn't use it by making a copy after each call to Read.

Modifying ReadAll to copy the slice returned from Read if Reader.ResueRecord was set would be simple enough. However I'm not arguing for any particular API.

I agree with @bradfitz that a method is likely a bit too much for this simple optimization. I'm currently thinking about something along the lines of:

	// If ReuseRecord is true, calls to Read will reuse a single record slice.
	// When a record doesn't fit into the currently held slice, a new slice will
	// be allocated and used for succcessive calls to Read instead.
	// If set to false, each call to Read returns a fresh slice.
	// ReadAll is not affected by this setting.
	ReuseRecord bool

I'm not completely sure about the second sentence, but I think it can help avoid some potential confusion. This definition also makes clear that ReadAll is not affected.

I also tested a version with ReuseRecord locally and found no difference between ReadInto and ReuseRecord (as expected).

@nussjustin @bradfitz SGTM

CL https://golang.org/cl/41730 mentions this issue.

Sorry for the delay. I finally got some time (and internet!) to mail my change.