proposal: strconv: Add Parse[T]

[icholy]

I'd like to propose a generic interface to the parsing functionality provided by strconv.

type Types interface {
	string | bool | int | int8 | int16 | int32 | int64 |
		uint | uint8 | uint16 | uint32 | uint64 | uintptr |
		float32 | float64 | complex64 | complex128
}

func Parse[T Types](s string) (T, error)

This would mainly be used from other generic functions. For example:

func QueryValue[T strconv.Types](q url.Values, key string) (T, error) {
	v := q.Get(key)
	if v == "" {
		var z T
		return z, fmt.Errorf("query value not found: %q", key)
	}
	return strconv.Parse[T](v)
}

[seankhliao]

Wouldn't this have to use a big type switch internally?

How often does this come up that it needs to be in the standard library?

[icholy]

Wouldn't this have to use a big type switch internally?

Yes.

How often does this come up that it needs to be in the standard library?

I've needed it about 3 times now. Writing that big type switch is very tedious.

[DeedleFake]

I don't think a single Parse[T Types]() would work because there are varying options to set for each type. However, I'd really like variants to the existing Parse*() functions that does the conversion internally. My issue with them is generally that because they return two values, I wind up having to pollute the local namespace with an extra variable for each parsing unless I happen to want the one it happens to return. For example,

v64, err := strconv.ParseInt(str, 10, 0)
// Check error.
v := int(v64) // Can't do the conversion inline with the call above.

That's quite annoying, but it's relatively minor. If generics get default types or something, it would be nice to see those functions made generic so that I could just do v, err := strconv.ParseInt[int](str, 10, 0), or even var v int; v, err := strconv.ParseInt(str, 10, 0) with return-based inference.

[dsnet]

\cc @josharian. Seems similar to his atox package.

[apparentlymart]

I tried a different implementation of Parse in terms of fmt.Sscanf here: https://go.dev/play/p/OLs0uTqBhCi

The most relevant part:

func Parse[T Parseable](str string) (T, error) {
	var result T
	_, err := fmt.Sscanf(str, "%v", &result)
	return result, err
}

I don't think it would be possible for this specific implementation to live in strconv because IIRC fmt relies on strconv, but given the existing division of labor between strconv and fmt -- the former deals with specific types and all of the finicky special options for each, while the latter "just does what you mean" -- perhaps this utility would be more at home in fmt anyway.

It feels perhaps like what fmt.Scan might've been if fmt had been designed for a generics-capable language. (Although that function supports more than one argument.)

With all of that said, I'm also not feeling super convinced about this being in stdlib. This fmt-based implementation is relatively short to copy-paste into a package that needs it, and when I want something more involved than this I tend to want more control over exactly how each type would be handled anyway and so I probably wouldn't reach for an all-purpose stdlib function like this one. And the aforementioned josharian/atox seems to already have the slightly longer switch-statement-based version.

[icholy]

I had no idea you could use %v in the scan functions.

[earthboundkid]

I am against “useless uses of generics.” The signature should be Parse(s string, ptr any) error instead. The calling code will be just as long either way because you need to add [type] with the faux-generic version.

[apparentlymart]

Hmm indeed and further to @carlmjohnson's point, if a proposal like #57644 were accepted then it could become possible to use a sealed type set for an interface value.

If the implementation is going to immediately wrap the given value in any and use dynamic dispatch for it anyway, perhaps better for the signature to be honest about that.

With that said, I can see the attraction of a form that returns a value rather than writing through a pointer. It tends to lead to (subjectively) more "normal-looking" code. But for a case like this I'm not sure it is worth it, especially since "write through a typed pointer" is already the typical API style for unmarshal-like functions in Go.

[icholy]

@apparentlymart The assumption is that the overhead will go away once we have something like #45380

[earthboundkid]

If #45380 existed, this would not be a "useless use of generics", but for now at least, it doesn't and best practices documents specifically call out not using generics for deserialization. Also, maybe I'm idiosyncratic, but I try to arrange my generic functions so that the type inference means I rarely if ever need to explicitly use a type specifier. That means I prefer Parse(s, &x) over x = Parse[int](s).

All that said, I too have written a function like this before, so it's clearly something users want, whether we should or not. :-)

[icholy]

best practices documents specifically call out not using generics for deserialization

Link? (not disagreeing, just curious).