I'm planning on just deprecating the ParseError.Column field. It's meaning is sometimes ambiguous and it is a hit to performance to even compute it. At least one other error ErrFieldCount has no use for the column.

Change https://golang.org/cl/72050 mentions this issue: encoding/csv: deprecate ParseError.Column

I'm kicking this over to NeedsDecision. Anybody want to weigh in on whether deprecating Column is the right move? Looks like the field dates back to the initial implementation of the package by @pborman in https://golang.org/cl/4629085.

I think it would be unfortunate to deprecate this field. Being told a " is wrong in a line with 23 "'s might be difficult to find.

As commented on the CL:

Maybe it would make sense to replace (deprecate in favor of) ParseError.Column with a new field that contains the current record number (basically the current len(r.fieldIndexes)+1)? Unlike the column, the field number should always be meaningful, even for ErrFieldCount (where it would be the actual len of the record).

Knowing the field number is nice, but it still requires quite a bit of parsing for the human reading the error. For CSV files with few fields and simple values this is not an issue, but for CSV files with a large number of fields or longish fields this probably doesn't help a lot.

When debugging there are several pieces of information that is helpful:

1. The line that the record started on
2. The line:column that the problem field started on
3. The line:column where the problem was actually detected

Note that all 3 pieces of information are distinct. In go1.9 and before, it used approach 3. However, with badly quoted strings, this is untenable since what the parser considers the problem is sometimes very far from what a human would consider the problem (which is the start of the record or field). As a result of #19019, the error was changed to be 1, in which case the column number is already senseless.

A better error message would combine information in 1 and 3.

Imagine the following:

• record on line 2: wrong number of fields
• parse error on line 5, column 32: extraneous " in field if starting line and error line are equal
• record on line 2; parse error at line 5, column 32: extraneous " in field

Thoughts on this? While information in 2 is useful, it is also not performance friendly to keep that information around.

I agree that ParseError.Column is nice and somewhat I would expect from an error when reading a CSV file, but I also agree with @dsnet that the error he got makes no sense and it's not the only case where Column doesn't make sense (ErrFieldCount comes to my mind, at least it't not really what most people would expect from my experience)

Even if we keep ParseError.Column I'd like to see a field with the current field index for the simpler cases where you don't have that many columns and/or long fields, ParseError.Column isn't that helpful or you are just trying to find the error in a tool like Excel (which many people do) where you can more easily jump to a specific column (although this wouldn't work for all errors).

Didn't see @dsnet's comment pop up before submitting mine, so here I go again:

I like that idea. CL 52830 isn't even released yet so maybe we could just change it back to report the error line and add two new fields StartLine and StartColumn. This way existing uses of ParseError Line and Column wouldn't change at all from Go 1.9 to Go 1.10 (unless I'm missing something) and we would still get the information and nice error message.

Change https://golang.org/cl/72150 mentions this issue: encoding/csv: simplify and optimize Reader

Change https://golang.org/cl/72310 mentions this issue: encoding/csv: add ParseError.RecordLine