Panics can happen in a data-dependent way about gcfg HOT 2 OPEN

Thank you for the feedback,. I agree that eager checking of the config struct would be a desirable feature, but I think the actual possibility of an error is rather hypothetical, making it low priority. Another thing to consider is that some people may be making use of the fact that struct checking is not eager, and include ancillary fields in their config structs, which currently works without issue (even though this is not the originally intended usage of gcfg). Based on this, rather than changing the behavior of the existing gcfg.Read* APIs to panic more eagerly, it seems more pragmatic to add a new optional and explicit API, such as gcfg.MustStruct, that checks a config struct and panics if invalid.

from gcfg.

Regarding adding new APIs to support new behavior, have you considered using a variadic options pattern as described here so that you wouldn't need to add new variants of ReadInto, ReadStringInto, and ReadFileInto every time there's a new option? Either that, or a single new API variant of each that takes an options struct.

from gcfg.