I agree that operators of this kind are useful; personally I've only wanted the string variant (QuotedPrefix) but it is frustrating when these complex (and evolving, albeit very slowly) routines exist but are inaccessible, and could be made accessible at no dynamic cost and with minimal maintenance cost.

I'm not a fan of how QuotedPrefix doesn't return the unescaped string, because then (in most use cases) you have to call strconv.Unquote later, which will loop over the bytes a second time to unescape it -- rather inefficient!

True, though Unquote is pretty cheap for literals that don't contain metacharacters, since it doesn't need to allocate.

#45033 added QuotedPrefix, which returns a valid quoted string that is at the start of the string. The decision was made that it does not actually perform the unquote operation, which must be done with a subsequent call to Unquote.

Following the existing precedence, I would expect the following be added:

• BoolPrefix
• ComplexPrefix
• FloatPrefix
• IntPrefix
• UintPrefix

where you would need to perform a subsequent call to ParseXXX after you obtain the leading prefix.

I think we should remain consistent.

I also like consistency, but here's what I don't like about FloatPrefix not returning the number (benchmark code here, with FloatPrefix implemented in terms of the existing readFloat function):

cpu: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
BenchmarkParseFloatPrefix-8           	28839720	        38.73 ns/op
BenchmarkFloatPrefix-8                	35758686	        30.83 ns/op
BenchmarkFloatPrefixAndParseFloat-8   	16890924	        67.09 ns/op

It's doing almost twice as much work when you need the float value (which I think will be common). It goes against the grain to be redoing work like this -- especially painful because parseFloatPrefix already exists and returns the number.

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

This still seems like a very complex function. What does it do with "1.2e+A"? Does it return "1.2"? Or does it report an error? It still seems like a text parser should be deciding this kind of error behavior for itself.

Another consideration: the function might not be forwards compatible if we change the grammar of numbers.

Prior to Go1.13, strconv.ParseFloatPrefix("123_456") would have returned 123.
After Go1.13 where we permit "underscore" separators, strconv.ParseFloatPrefix("123_456") would now return 123456.

This would break anyone who was relying on _ as a delimiter between numbers.

@rsc That's a good point. I don't think it'd be too hard to address, by just documenting whatever the current parseFloatPrefix behaviour is for that kind of case (which is to return an error, parsing "1.2e+A": invalid syntax).

@dsnet True -- another good point. Though that's very rare, and usually that would result in another error further up in someone's parsing.

Still, points taken. I'm definitely having second thoughts about whether this is a good idea, or whether people should continue to define their own pre-parsers specific to their domain (which is what I'm currently doing for GoAWK).

@dsnet, thanks. That's a great example of why I'm hesitant about this change. It's quite a bit more subtle than QuotedPrefix.

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

No change in consensus, so declined.
— rsc for the proposal review group