flyinprogrammer
commented
4 months ago Generally speaking, as someone who loathes the AWS Golang SDK and its pointers to everything and reinvention of types... I do believe their way of doing things is appropriate for Pkl. Pkl has strong opinions about null, and trying to marry them with Golang's default values seems like a ripe opportunity for footguns.
Personally, I'd much rather make people who are using Golang and Pkl care about nil value checking because then I never have to worry about tracking down bugs of the variety: Is that value coming from Golang defaults, our config file, or our library of config files? The answer is that the values always come from Pkl.
thomaspurchas
Hi,
I noticed every time I generate my Go structs, regardless of definitions inside .pkl files Go structs always contains struct pointers, never structs.
When I have structs generated from one type of config with pkl-gen-go and later on I pass a different Pkl module, that might not provide values for the generated structs - it is causing fatal, because I am trying to access property on nil.
It would be good to have a possibility to generate structs based on structs, than such attempt to access would return a default value for the type, like 0 or "". This could provide an easier way to fallback or fail, but not panic.
With current implementation it requires me to check all structs being nil embedded to my main Config struct, no matter whether default type value matches me.
Summing up: When valid Pkl module is loaded to the Go structs generated by pkl-gen-go it may lead to property being nil and and either triggers panic or requires additional validation.
Proposal: provide a mechanism to decide between Type.Pointer and Type.Declared when generating structs.