proposal: x/tools/stringer: add a Parse function to go from string to value

[fredrikelinder]

Extend stringer with the capability to go from string to value.

Inspired by https://pkg.go.dev/github.com/diegommm/tools/cmd/stringerParser

Usage:

//go:generate stringer -type Day -trimprefix Day
type Day uint8

const (
  DayMonday Day = iota
  DayTuesday
  DayWednesday
  DayThursday
  DayFriday
  DaySaturday
  DaySunday
)

func ParseDay(s string) (Day, error) {
  var d Day
  err := d.Parse(s)
  if err != nil {
    return d, err
  }
  return d, nil
}

Besides being useful when accepting input from a user this feature would also be useful when implementing default value struct tags for "enum" types.

[fredrikelinder]

https://go-review.googlesource.com/c/tools/+/434035

[robpike]

I'm pretty sure this has come up before, but I can't find the discussion. Anyway, there's already an external package to do this, as you cite, so there isn't a compelling need to compete with it in the tools repo. It even has the same interface. You can just use the external package.

Moreover, the full set of options and controls needed to solve this problem in general, the way people would want it with issues of casing and suffixes and prefixes and plurals etc., argues it should stay external.

Marking the CL as hold for proposal acceptance.

[mvdan]

Previously #23535. If you need to convert to and from string, I would argue you want a separate tool that generates MarshalText and UnmarshalText, since they are both standard interfaces. Then exposing a String method manually would be trivial.

[fredrikelinder]

The main reason I thought of stringer for this implementation is that stringer already implements the "enum"-type reading capability needed for this functionality.

MarshalText and UnmarshalText are good suggestions, as they more closely match what I'm looking for, so thank you.

The current implementation of stringer keeps only one of the same-valued constant names, as stringer has to make a decision of which constant name to string an underlying value as. This information is needed by a Parse or MarshalText implementation to go from any of its constant names to the a constant.

When reading the stringer implementation it appears that care has been taken to reduce the memory footprint needed for the String implementation (or else the map variant would always be used), and adding additional memory (the currently discarded strings) would be counter to that effort.

Alright, a separate tool it is. Just need to copy the type/const-reading code from stringer.

[mvdan]

Indeed, the code that stringer produces is only optimized in one direction and avoids overhead. A tool that also wants to do UnmarshalText efficiently might want something like a map[string]int too, for example.

[mcandre]

Please link to such a generator tool here in this conversation thread.

[mcandre]

By the way, generating a Validate() error method to reject values not covered by the enum declaration, would also be useful for making Go programs safer.