Support sections with no keys

[dimsuz]

Currently when I read this file:

[section0]

[section1]
key = value

the resulting map (and conf.sections() too) will only contain section1.
section0 will be silently dropped.

I didn't find any way to configure this crate so that sections with no keys are not skipped.

There are some use-cases where one wants to know if section is present (even if empty).

[QEDK]

This is an interesting edge-case, let me look into the parser implementation.

[QEDK]

The issue would arise from our handling of section headers,

configparser-rs/src/ini.rs

Line 486 in 1098ef7

continue;

we expect a non-empty map for each section, a section header followed by another section header means nothing is added to the map. This would be breaking change, what's the breaking use-case atm? @dimsuz The only relative way of fixing this would be using HashMap<String, Option<HashMap<String, Option<String>>>>.

[dimsuz]

My use-case is a bit of a weird one actually.

I'm using this library to parse an "ini-like" file format, which uses double-brackets to signify a higher level section, for example this:

[[Section1]]
[subsectionA]
key = value

[[Section2]]
[subsectionB]
key = value

should result in this hierarchy after parsing:

graph TD;
    Section1-->subsectionA-->keys1{{key=value}};
    Section2-->subsectionB-->keys2{{key=value}};

Loading

This is not strictly INI, but configparser is still able to parse it and my idea was to look for sections with name [Section1] (one level of [] gets stripped by the lib) and that would do it - I would be able to build parent-child relationships from there, sections being empty is OK, I would use indexed map and rely on order.

Currently this not working is not a big issue for me, so if it's impacting a library design or backwards compatibility I guess it's fine to close this issue and I'll have to stop being lazy and write some proper parser instead :)

[belak]

I've got an implementation in #50. I was able to do it without changing the API by just creating an empty HashMap when we encounter the section header, which seems clear enough - people who need to know about that edge case would be able to check if the hash map's .len() is 0 rather than checking against an Option.

Our use case is that having sections means that something is enabled, and allowing for extra configuration as options in that section. An empty section would mean it was enabled but there was no additional configuration.