proposal: Go 2: required fields on struct

[cyberhck]

This issue describes a language feature proposal to structs.
Depending on which path we take this might or might not break backwards compatibility.

Background

Say we have a API SDK, which can't function without http endpoint, api token, in other words, endpoint and api token are required, but user may or may not provide HttpClient (if he wishes to overwrite)

As of now, I'd say my struct would look something like this:

struct Options {
  Endpoint string
  Token string
  Client HttpClient
}

Just by looking at this someone doesn't know what to do, and if they don't pass in Token, it just crashes in Runtime:

x := Options {Endpoint: ""} // crashes during run time, not even on this line, but later.

I was thinking if this would benefit us:

struct Options {
  Endpoint! string
  Token! string
  Client HttpClient
}

and since those are required, initializing Options without those fields would throw a compilation error:

x := Options {Endpoint: "something", Token: "token"} // would be okay
x := Options {Endpoint: "", Token: ""} // would be okay
x := Options {Endpoint: "something", Token: "token", Client: getClient()} // would be okay
x := Options {Endpoint: "something"} // would error compiling
x := Options {Endpoint: "something", Client: getClient()} // would still error while compiling

I understand this is a language change and could be solved using constructors, but adding those would mean we detect stuff early while compilation.

Personally I like if everything is required by default and use ? to say optional (like regex), but that'd break the whole golang ecosystem (and that'd be for golang 2), but introducing ! (or any other operator) shouldn't break anything, that I know of.

I heard there was a proposal for safe pointer which could never be nil, this is similar to that, but for struct fields, including string or int or any type.

[mvdan]

Please note that all changes to the language should go through the proposal process: https://github.com/golang/proposal

[ianlancetaylor]

Is it also an error to assign the zero value to such a field? If the assignment is done via a variable, as in x.Endpoing = str where str happens to be the empty string, what happens?

[agnivade]

I would also like to add that protocol buffers and other projects achieve this through struct tags and reflection.

type Options struct {
  Endpoint string `required:"true"`
  Token string `required:"true"`
  Client HttpClient
}

Not a compile time check ofcourse. But explicit enough and you have to write the code only once for all structs.

[cyberhck]

In case you're using a variable, it'd take the type of the variable, if type of variable is assignable to type of that struct field, then that should be fine, if a variable is set to empty string, but struct field says it should be number, of course that won't pass, that's the case right now as well, similar thing with empty string, type checking, empty value should behave like what is currently being done right now.

All we enforce is requirement. The way @agnivade mentioned, if we were to use that, we can already write a lint rule for this, go through each struct initialization, check each struct field's definition, and see what are required, and see if all required fields are initialized while declaration.

That's not being done in compile time as of now of course, but given AST, I think we can determine that in compile time.

Think of it like TypeScript interfaces, while initialization, we check if required fields are present.

Is it also an error to assign the zero value to such a field? If the assignment is

Well, what happens right now? You CAN pass empty string to it, I think I mentioned in my proposal. Empty string is also a string, so that's there. Another thing would be, I'm asking to enforce proper types, that's already done by golang on compile time, you can't pass in integer to a string field, but you can pass empty string to string field. All we're looking for:

• parse AST and find any struct initialization
• for that struct look at definition
• get list of required fields on that struct definition
• for this particular struct initialization, check if all required values are present.
• if everything is present, it's quite alright
• if something isn't present, we throw compilation error.

I think we can avoid breaking change with this.

[deanveloper]

Just by looking at this someone doesn't know what to do, and if they don't pass in Token, it just crashes in Runtime

Well, what happens right now? You CAN pass empty string to it, I think I mentioned in my proposal. Empty string is also a string, so that's there.

These seem like they are very conflicting statements. Not providing an argument is equivalent to passing in an empty string.

[deanveloper]

x := Options {Endpoint: "", Token: ""} // would be okay

x := Options {Endpoint: "something"} // would error compiling

This isn't really adding any safety then... Plus, you still have to do as much error checking wherever you use x.Token. I really don't see the benefit in this

[themeeman]

This proposal essentially wants something to be checked at compile time that really shouldn't be checked at compile time. Just use a constructor function.

[cyberhck]

I think I phrased to issue wrongly, or I missed something I think I understand what I meant, is there a way to ensure in go to say "this field of struct can't be null"? Like NonNull in Java? Obviously for some primitive types like string, I don't think there's a way to make it non nullable.

[deanveloper]

If your goal wasn't supposed to work with strings, then your examples don't make any sense, because they use strings...

Does anyone know if there is already a proposal for nil safety in Go?