Proposal in brief
Add a keyword like "exhaustive" to compile-check that all fields in a struct instance creation are informed/filled.

Example and related issue
In the corresponding code:

type foo struct {
  a string
  b string
  c string
}

func main() {
  var f = foo{
    a: "hello",
    b: "world",
  }
  fmt.Printf("%v\n", f)
}

I think there is a danger here (which is not specific to Go, it also exists in C,C++, or many object-oriented langages): "c" has not been filled and will have its default empty string value. It may perfectly be intentional (filling fields is optional and it allows flexibility), but in some cases it may also not be: maybe this "c" field has been added afterwards and the developer may have forgot to correct all corresponding struct creations.

Proposed solutions with examples

1. The proposal is to create a keyword like "exhaustive" which would cause a compilation check that that all fields are filled in
that struct creation statement.

type foo struct {
  a string
  b string
  c string
}

func main() {
  var f = exhaustive foo{
    a: "hello",
    b: "world",
  }
  fmt.Printf("%v\n", f)
}

This code would generate a compilation error: "exhaustive keyword with missing field in struct foo: c"

Of course, this keyword would also be accepted on function calls like any normal statement:

fmt.Printf("%v\n", myFunction(exhaustive foo{a: "hello"}))

2. An even bolder idea: the "exhaustive" keyword on the struct type declaration would forbid any struct creation where a field declaration is missing.

type foo exhaustive struct {
  a string
  b string
  c string
}

func main() {
  var f = foo{
    a: "hello",
    b: "world",
  }
  fmt.Printf("%v\n", f)
}

This code would generate the same compilation error.

3. Another totally different approach: a keyword for "compulsory" fields.

type foo struct {
  a string compulsory
  b string
  c string
}

func main() {
  var f = foo{
    b: "hello",
  }
  fmt.Printf("%v\n", f)
}

Compilation error, not because of "c" which remains optional, but because of "a".

Go 2 language change template

Would you consider yourself a novice, intermediate, or experienced Go programmer?
Intermediate, I don't know.

What other languages do you have experience with?
Perl, C, C++, PHP, Bash, Mysql, and a bit of Java, Javascript, Python

Would this change make Go easier or harder to learn, and why?
Slightly harder but the feature is kinda simple, and optional to use which makes it a less imperative feature to know.

Has this idea, or one like it, been proposed before?
Not found in github issues.

Who does this proposal help, and why?
Developers wanting the most robust code possible.

What is the proposed change?
Please describe as precisely as possible the change to the language.
What would change in the language spec?
Please also describe the change informally, as in a class teaching Go.
(see above).

Is this change backward compatible?
Would break code where the keyword "exhaustive"/"compulsory" is used as a type/variable, but maybe it could be possible to accept it nevertheless and distingish a type/variable from the keyword, depending of the implementation.

What is the cost of this proposal? (Every language change has a cost).
Slightly higher language maintenance.

How many tools (such as vet, gopls, gofmt, goimports, etc.) would be affected?
Several, depending on implementation.

What is the compile time cost?
Presumably low.

What is the run time cost?
Absolutely none. The binary program generated would be strictly the same provided that compilation passes.

Can you describe a possible implementation?
No. I just assume that it would impact the code that parses the struct statements.

Do you have a prototype? (This is not required.)
No.

Orthogonality: how does this change interact or overlap with existing features?
Interacts with the way struct and declaration works.

Is the goal of this change a performance improvement?
No.

Does this affect error handling?
No.

Is this about generics?
No.