Thanks for the proposal.

This is, of course, just syntactic sugar. In Go we normally reserve syntactic sugar for cases where it would be very widely used. This doesn't seem like such a case. Also the emoji voting is not in favor. Therefore, this is a likely decline. Leaving open for four weeks for final comments.

I've collected some data.

The repo https://github.com/jimmyfrasche/issue57949 includes the collection tool

The gist https://gist.github.com/jimmyfrasche/217805adc3c17d997e0dd0c493b5b5a1#file-notes-and-summary-md contains totals and the raw data for std and 10 large projects.

For easy reference here are the totals

keyed struct literals: 42404
total KV pairs: 101954
non-candidate KV pairs: 75571
ident:
	total: 18504
	no match: 8359
	exact: 6957
	partial: 3188
qual.ident: 
	total: 7123
	no match: 4889
	exact: 2234
	partial: N/A
*ident:
	total: 59
	no match: 46
	exact: 7
	partial: 6
*qual.ident:
	total: 25
	no match: 15
	exact: 10
	partial: N/A
&ident:
	total: 505
	no match: 360
	exact: 13
	partial: 132
&qual.ident:
	total: 166
	no match: 124
	exact: 42
	partial: N/A

It's explained in the links but partial matches are a != b && string.EqualFold(a, b) to catch cases like Title: title.

This change would also make code harder to navigate. When you see T{x: x}, you have the choice of asking your IDE the question "where is field x defined/referenced?" or "where is var/const x defined/referenced?" by selecting the different identifiers. If there was only one, it would require more work to get around the code.

@alandonovan I've never really looked at the language server protocol so I'm not sure what headaches it would cause there but I don't see why the context menu couldn't provide both options in this case.

I'm not sure what headaches it would cause there but I don't see why the context menu couldn't provide both options in this case.

FWIW, that's not how LSP works. The protocol has no concept of a "context menu". It has a fixed set of operations such as "report the definition of the selection" or "report references to the selection", and these are exposed by the editor however it chooses, e.g. as menu items or commands. But the server doesn't get to choose the UI. So for T{:x} the server would be forced to compute the references (or definitions) of both meanings of x and report them all as one big union.

If there was only one, it would require more work to get around the code.

Jumping to the definition of the struct field for the cursor is conceptually very similar to jumping to the definition of the function parameter containing the cursor. Does LSP support that today? If so, could the same mechanism be use for struct fields?

Jumping to the definition of the struct field for the cursor is conceptually very similar to jumping to the definition of the function parameter containing the cursor. Does LSP support that today?

Yes, they are identical: jump to definition of selected identifier. That's my point: LSP has only one flavor of "jump to definition" operation, but the introduction of the proposed change would create the need for two flavors of query.

The closest existing situation is that of embedded fields: struct{T} is both a reference to type T and a definition of a field T. The two meanings of the pun on T are opposite so it's obvious from the query what do to: if you ask for the definition of T, the server reports the type definition; if you ask for the references, it reports references to the field (but not the type). However in the proposed change the puns are both references so the protocol offers no obvious way to tease the queries apart.

(Also: the go/types API has no way to indicate that a single identifier is a reference to two different objects, so many tools would be broken by such a change.)

Using a VS Code project where I had something similar to:

type v struct { 
  x string // L0
}
 
func f(x string) *v { // L1
  return &v{
    x: x, // L2
  }
}

On L2 I can press F12 (Go to Definition) on the first x to go to L0 or the second x to L1.

I'd personally be fine if F12 just went to L1 for :x. I can still use go to type definition on &v. That's not that hard.

A jump to field definition that worked on either x would probably be handy even modulo this change. I'm not sure it should be a blocker.

Does anyone have experience with any Haskell/Ocaml/Rust LSP servers? What do they do in this case?

LSP has only one flavor of "jump to definition" operation, but the introduction of the proposed change would create the need for two flavors of query.

I guess what I'm saying is: given that we already have function parameters, it seems to me that we already have the need for two flavors of query. This proposal might draw out that problem more frequently, but it's an existing problem with the LSP protocol either way.

@adonovan

(Also: the go/types API has no way to indicate that a single identifier is a reference to two different objects, so many tools would be broken by such a change.)

In the first post I state that the go/ast should encode :x the same as x: x with some hint to formatters that it should be output as :x to avoid breaking tools

The only real downside mentioned so far is go to definition. I don't really see that as a showstopper and given how many big languages already support this (many more support it but they are all fairly niche) I would hope LSP grows the necessary primitives to handle this case.

Let me do a brief and simplistic analysis of the data I gathered. I'll ignore everything except the currently proposed simple identifier case. In the 11 modules (counting std as a module) analyzed, there were 1986 packages and 1339 (67%) contained keyed struct literals.

There were 101954 KV pairs total spread across those literals. Of those, 18504 (18%) had a simple identifier for the value and 6957 of them had identical key and value. That's about 38% of KV pairs where the value is a simple identifier or about 7% of all KV pairs.

That's not bad. That is in the language as it is today, though.

If this feature were to be adopted, I conjecture that there would be a stronger incentive to name more of the identifiers identically. There were 3188 matches that would be identical if not for case. Some of those may have good reason but let's say that 95% would be written with identical case given this proposal. Similarly let's say of the 8539 identifiers that didn't match at all, 50% would have been written identically. That gives us approximately round(0.5×8359 + 0.95×3188 + 6957) = 14165 KV pairs that would have used the :shorthand, or about 75% of KV pairs where the value is a simple identifier or 14% of all KV pairs.

I can't say if that counts as "widely used", as @ianlancetaylor put it, but it's still pretty good bang for the buck.

If that counts, let's look at its effect on writability, readability, and editability.

Writability is an easy win. You can type a name once instead of twice. Even without this you are generally choosing a name for your identifier that is close to the name of the field (you don't see a lot of Red: Green) so unless the field name is just huge and messy might as well just name it identically and write less in total.

Readability isn't as obvious but I think it's also a win. You can usually tell at a glance if a name is Twice: Twice but sometimes you may have to double check which doesn't apply if it's only written :Once. More importantly it's just lighter on the page and less repetitious.

Editability is a bit harder in the case of renaming the identifier or the field. The field name is unlikely to change but the problem is symmetric and you may need to change the identifier. In either case gorename could easily handle this case and expand :X to X: Y as necessary (if it wouldn't just do it automatically given the suggested encoding in go/ast). I imagine it would also be easy to include editor macros to go from X: X to :X and vice versa. For the most part I don't think this would come up too often for new code and would probably mostly be an issue for someone wanting to rename an identifier to take advantage of the new sugar. Given that it's easily automated I am unconcerned.

Just subjectively I'd add that having used languages with this feature more I find myself getting annoyed when having to repeat myself in Go. It feels wrong and there's an easy fix.

Writability is an easy win. You can type a name once instead of twice. Even without this you are generally choosing a name for your identifier that is close to the name of the field (you don't see a lot of Red: Green) so unless the field name is just huge and messy might as well just name it identically and write less in total.

Wearing my devil's advocate hat, I wonder whether encouraging people to use the same name for the var and the field is always desirable: perhaps today they choose a more specific and informative name for the var.

In any case I don't think tools such as gopls should be the primary consideration in the language design. Thanks for the analysis.

I don't think it's always desirable but I do think that it quite often is.

I used the example of Red: Green as something that basically never happens because you're generally doing one of

• Red: Red
• Red: red
• Red: c

Either a name that is close to if not exactly the field name or a nondescript name.

There can definitely be good reasons for going with the last one (annoyingly long field name, c gets used in more than one place, etc.).

The :x shorthand would strongly encourage you to use an identical name instead of a basically-close-enough name and weakly encourage using an identical name instead of a nondescript name.

I didn't try to count abbreviations or "close enough" names but as I was glancing through random files the names that weren't exact or partial tended to either be an abbreviation of some kind or something nondescript.

When writing in languages that support this feature I default to using the identical name but diverge if I have a good reason not to. It saves a little bit of thought when it doesn't matter and when it does not using the feature adds an extra clue in the text that something unusual may be happening.

I patched in a quick hack to log the 8359 no match identifiers (not == or equals fold). I filtered out the uninteresting case of the value being nil, true, or false, reducing it to 6649 entries. I ran those through sort and uniq, reducing it to 3760 entries. I saved this as nomatch.set then ran shuf -n100 nomatch.set | sort >nomatch.samp. I manually partitioned them into 3 piles

1. shorter: value is abbreviation of key: 19
2. longer: key is abbreviation of value: 32
3. no relation: names don't obviously coincide: 49 (I could probably have shunted more of these into one pile or the other if I were more lenient about "obviously")

If this is representative, my intuition about no matches was a bit optimistic. About 50% are abbreviations but I wasn't expecting so many K to be the abbreviation of the V.

The new data files are in this gist: https://gist.github.com/jimmyfrasche/4b80780ea40b79f9c51a158f78e263bf

Based on the empirical sample, I'm lowering my estimate for nomatch from 50% to 15% and
round(0.15×8359 + 0.95×3188 + 6957) = 11239 lowers it from 14% to 11%.

However, I think I should have filtered out the predeclared identifiers. They are, for our purposes here, more akin to constants than identifiers and should have been counted in the noncandidate pool. Making that adjustment gives round(0.15×6649 + 0.95×3188 + 6957) = 10983 but that still keeps it at 11% (first 11% is rounded down and this one is rounded up).

Thanks for the additional discussion and data. However, it doesn't tip the balance for adding new syntactic sugar. Closing.