config files with 'extra' content about gcfg HOT 4 OPEN

Thank you for the feedback! It is a valid request, but at the same time I do 
have some concerns about it.

It is not stated explicitly in the package docs, but the thinking behind 
disallowing "unexpected" data (variable, section, or subsection) is similar to 
that for unused variables in Go: it can indicate configuration mistakes, e.g. 
using mismatched versions of a utility and its config file.

> I've got a project with a config file shared amongst several utilities...
Depending on the level of cohesion among the utilities, I'd consider sharing 
the config struct, or splitting configuration into shared and utility-specific 
files. Would one of those not be suitable in your case?

> ...and some test/work-in-progress settings.
To be honest, I don't find "experimenting" a very convincing argument for 
ignoring extra data. (The rationale is the same as above.) In addition, just 
allowing extra (sub)sections (but not extra variables in "known" sections) also 
would seem somewhat arbitrary.

One approach could be to continue parsing on extra data and return a separate 
kind of error, so that the caller can decide to ignore it. Another one (which 
I've been trying to avoid) is to add some configuration for gcfg itself. But 
I'm not convinced if either is worth the added complexity.

I like your thinking; it's a completely valid point.

I'll go back and have a look at the project and see if I can go about it a 
different way that fits better with Go methodology.

One use case strikes me: upgrades.
If I add a config field to the struct, then any existing config files out there 
in existing installations will immediately be invalid and will refuse to load. 
In order to update them I have to load the data from the existing file and add 
any missing fields, but I can't do this using the gcfg library (which would 
seem to make sense).

Maybe creating an upgrade utility that 'knows about' previous config file 
versions and loads the config file using an older struct and then modifies it 
to the latest version, but that seems like a lot of work for a simple problem?

Upgrade should not give an error unless you remove some sections / variables in 
the config struct. (I.e., missing values for declared variables do not cause an 
error, but values provided for undeclared variables do. Sorry, maybe my 
comparison with unused variables in Go was confusing -- the rationale is 
equivalent but "unused" applies in a different way.)

Updating gcfg files programmatically is currently not supported. So in case 
supporting upgrades (with new config fields) without change of configuration 
file is needed, the application must make sure that it will work even if the 
user doesn't provide values for the new fields. (E.g. handling zero-values 
accordingly, or pre-populating sensible defaults etc.)

Downgrades can cause an error if new variables have been added to both the 
config struct and the config file, and then only the application is downgraded. 
I tend to think this behavior is better than silently ignoring the values that 
are not supported by the prior version.