Just noting that this would mean that struct tag keys cannot contain a comma character. The current documentation at https://golang.org/pkg/reflect/#StructTag is "Each key is a non-empty string consisting of non-control characters other than space (U+0020 ' '), quote (U+0022 '"'), and colon (U+003A ':')." So this would be a change. Of course, it's fairly unlikely that anybody is using a tag key with a comma.

It could be a breaking change of course.

I have a large corpus of Go code that I can scan at some point to see if anyone uses , in tag names in practice.
Will try to do that before next week.

What if we use a space-separated list instead of a comma-separated one?

type MyStruct struct {
  Field1 string `json bson xml form:"field_1,omitempty" other:"value"`
}

The spaces form is more analogous to what happens in Go argument lists:
in x int, y int, z int, you can remove the repeated int, leaving x, y, z int.
If we do the same here, then
in json:"x" bson:"x" xml:"x", you can remove the repeated :"x", leaving json bson xml:"x".
If we inserted commas during this step, you'd need to explain where they came from
(they weren't there before!).

The space form is also quite a bit less of a wall of text and thus easier to skim. Compare:

Field1 string `json bson xml form:"field_1,omitempty" other:"value"`
Field1 string `json,bson,xml,form:"field_1,omitempty" other:"value"`

And unlike comma, spaces cannot appear in valid tags today,
so we would not be redefining technically valid syntax to mean
something slightly different.

Space-separated is much better and it indeed looks like Go argument list.

Regarding proposal: I haven't use more than 1 file tag (json or yaml) before, but last week have played with different config files and leaving all this verbose repetitions (field1 for JSON, also for YAML, also for TOML, also for ...) will make multi-tags much easier to use.

I must admit that space separated could be a good idea which won’t break anything.

Personally I feel it less comprehensible than comma separated and in go we have comma between arguments (we don’t write a b c int so comma is more go in fact lol ok i did understand why space is more go in fact) but a choice have to be made and don’t belongs to me :)

Even with space separated, the main issue is resolved so it’s ok to me ! ;)

OK, so with the syntax I suggested last Thursday (space-separated instead of comma-separated keys), there is no concern about backwards compatibility. There hasn't been much discussion otherwise.

I did make some progress analyzing tags in my Go corpus last week, and I found that 0.06% of tags have commas in keys (outside quoted values). All of those are mistakes. So we could plausibly use comma and not break things, but the space is more in keeping with the current syntax anyway.

Based on the discussion above, this seems like a likely accept (with spaces, not commas).

To be clear, the new syntax would be:

type MyStruct struct {
  Field1 string `json bson xml form:"field_1,omitempty" other:"value"`
}

No change in consensus, so accepted.

Hi! I would like to work on that feature. Is it possible? :)

Sure, go ahead.

Change https://golang.org/cl/248341 mentions this issue: reflect: added multiple keys support for struct tags

Change https://golang.org/cl/281237 mentions this issue: doc/go1.16: remove note about reverted reflect change

Change https://golang.org/cl/281973 mentions this issue: Revert "go/analysis/passes/structtag: recognize multiple keys per tag"

Change https://golang.org/cl/281515 mentions this issue: Revert "reflect: support multiple keys in struct tags"

Change https://golang.org/cl/282412 mentions this issue: cmd: update to latest golang.org/x/tools

Everything is backed out now.

If you can be 5X more productive with this feature then it means you spend at least 80% of your time writing struct tags.
I'm sorry to hear that and encourage you to write a program to do that for you.

What about this?

type MyStruct struct {
  Field1 string `json/bson/xml/form:"field_1,omitempty" other:"value"`
}

The issue discussed here is the same... It's not a problem from the selected char but the splitting itself. So, using / won't resolve it. I'm the first impacted from the rejection of that feature but.. yeah, it's life dude. Let that feature dead :)

go-sftag Yet another StructTag

type ConnParams struct {
	Host     string                 `json:"host" yaml:"host" toml:"host"`
	Port     int                    `json:"port,omitempty" yaml:"port,omitempty" toml:"port"`
	Username string                 `yaml/json:"username,omitempty" toml:"username"`
	Password string                 `toml/yaml/json:"password"`
	Database string                 `toml/yaml/json:"database"`
	Options  map[string]interface{} `yaml/json:"options,omitempty" toml:"options"`
}

The idea is good but how to make it work with json.Marshal for exemple ? Because it uses the internal tag library. :)