Presumably it's better to break brittle targets once, rather than repeatedly.

I agree. Do we have more suggestions, though?

whether SyntaxError.Offset should be part of the error message string?

That could be a good idea, but how would you render it in the string? If you use ${offset}: ${message}, I think most people will incorrectly read the number as a line number and not a byte offset. We could go for ${message} at byte offset ${offset}, but it feels too wordy.

Another reason not to do it is that, right now, Error() is the only way to obtain just the message string. It might need to be coupled with exporting the msg string field.

At the same time 50 targets is a non-trivial number of breakages.

At this point I've learned to not try to argue with test breakages :)

Yikes. I did try to search on Github for code snippets that this change could break, but that search wasn't exhaustive and probably Google writes better tests.

I think backing this change out is the right thing to do.

To be clear, these tests are brittle and shouldn't depend on the exact text of stdlib errors. We're fine with dealing with it internally. However, 50 tests is more than we usually see break from a changed error message, which might point at this having more impact than expected in the ecosystem at large.

Change https://golang.org/cl/273747 mentions this issue: encoding/json: revert "add "json: " prefix to SyntaxError messages"

Looking at things like the mod_proxy_invalid.txt message, I think leaving the prefix out makes a lot of sense. Let's just revert it please. What's done is done.

I think leaving the prefix out makes a lot of sense

A bigger discussion, I guess, but if it doesn't make sense to prepend the package name prefix in this case, I'm wondering why we have this convention in the standard library at all. I've noticed it's funky to expose Go errors to frontend clients in a browser UI context.

@kevinburke, yes, in general I think that rule is clearly not something to apply 100% of the time.

io.EOF is "EOF" not "io: EOF". And os.Open("nonexist") returns an error that says "open nonexist: file does not exist", not "os: open nonexist: syscall: file does not exist".

@rsc, I would expect it to be consistent within a package, though. All other errors within the json package have a json: prefix.