I think this proposal makes sense; having to find the end of the quote manually means reimplementing a basic version of Unquote.

I also wonder if the input should be a []byte; I realise the package is called strconv, but the use case is precisely about reading and buffering, where one almost always has a byte slice. The fmt and reflect examples you show have to explicitly convert to string before calling strconv, for example. I think the result is less important, as it's possible to construct the result with a strings.Builder.

It may be that the operation to expose is "find me the end of this string" and not "also Unquote it".
I was discussing recently with Austin about adding a similar operation to regexp/parse, but I was thinking it would be separate from actually parsing. You don't always want to parse it, but you always need to identify a boundary.

That sounds more flexible, with the downside that one would end up looping over the input bytes twice. That already happens today, so perhaps the cost isn't significant enough to matter.

Given that many strings do not have any escape characters, the operation could report whether the string had any escape characters. If not, the user could trivially truncate off the leading and trailing quote characters and avoid a second pass.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

So if we do the string-end-finder, I guess the API would be:

package strconv

// QuotedPrefix returns the quoted string (as defined by Quote and Unquote) at the prefix of s.
// If s does not start with a valid quoted string, QuotedPrefix returns an error.
func QuotedPrefix(s string) (string, error)

?

Reporting the presence of absence of escape characters seems like premature optimization.

Wouldn't you need to know where the prefixed quoted string ended so that the caller can start parsing what comes afterwards?

Reporting the presence of absence of escape characters seems like premature optimization.

I agree. In my all my use-cases, performance was not paramount. Also, this loop does not seem hard to write in the extremely performance sensitive cases.

Wouldn't you need to know where the prefixed quoted string ended so that the caller can start parsing what comes afterwards?

You can call the len function on the result.

Ah yes, I apologize. I missed the part where it "returns the quoted string".

I feel like an API that simply returns the length of a valid quoted string (and the entire length otherwise) is simpler to use.

Suppose we had:

// QuotedPrefixLen returns the length of the quoted string (as defined by Unquote) at the prefix of s.
// If s does not start with a valid quoted string, QuotedPrefix returns len(s).
func QuotedPrefixLen(s string) int

For example, if I wanted to parse the following text:

"string1" "string2" "string3"

the code would look like:

in = strings.TrimSpace(in)
for len(in) > 0 {
    n := strconv.QuotedPrefixLen(in)
    s, err := strconv.Unquote(in[:n])
    if err != nil {
        ...
    }
    ... // make use of s
    in = strings.TrimSpace(in[n:])
}

Alternatively, with the QuotedPrefix API, you have to do an additional error check:

in = strings.TrimLeft(in, " ")
for len(in) > 0 {
    s1, err := strconv.QuotedPrefix(in)
    if err != nil {
        ...
    }
    s2, err := strconv.Unquote(s1)
    if err != nil {
        ... // technically this will never happen, but it's not obvious to reviewers
    }
    ... // make use of s2
    in = strings.TrimLeft(in[len(s1):], " ")
}

That said, I'm still okay with QuotedPrefix as its better than nothing.

I feel like an API that simply returns the length of a valid quoted string (and the entire length otherwise) is simpler to use.

Suppose we had:

// QuotedPrefixLen returns the length of the quoted string (as defined by Unquote) at the prefix of s.
// If s does not start with a valid quoted string, QuotedPrefix returns len(s).
func QuotedPrefixLen(s string) int

For example, if I wanted to parse the following text:

"string1" "string2" "string3"

the code would look like:

in = strings.TrimSpace(in)
for len(in) > 0 {
    n := strconv.QuotedPrefixLen(in)

Would QuotedPrefixLen return 0 if there's an escaping error inside the quoted prefix?

I guess if that's the case, you could still call Unquote on the full string and it'll produce the expected error, so it'll work out OK.

I struggled between having it return 0 or len(s) on error situations. The advantage of returning len(s) is that naive slicing of the input would pass an invalid string to strconv.Unquote, which would then produce a good error message. The downside is that you can't distinguish between a valid string that happens to be the full length or an invalid one.

Have it return (int, bool)? You could just ignore the boolean result if you don't need it.

You can always wrap QuotedPrefix to get the single-result.
Returning the error lets you get specific information about what went wrong,
which the sentinel integer does not.

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

@rsc, To be clear, we're going with the API you proposed in #45033 (comment), right?

Returning the error lets you get specific information about what went wrong,

I just took a look at the implementation of strconv.Unquote and it always returns strconv.ErrSyntax no matter what. I'm not sure how much the rationale of "getting specific information" applies. I would expect strconv.Unquote and strconv.UnquotePrefix to return the exact same error for some invalid input. It's not clear to me that we can (due to Hyrum's law) nor should (due to performance implications) make strconv.Unquote give more informative errors.

Change https://golang.org/cl/314775 mentions this issue: strconv: add QuotedPrefix