Subsections should be made available in an sorted order

[GoogleCodeExporter]

It would be a nice feature if there was some way to get an array of pointers to 
the subsections read in by any of the Read*Into functions. My use case has 
subsections that are named but define parts of a pipeline which should be 
configured differently based on the order that the subsections appear.

I.E.
# inputs will routed to the processor who's "match" pattern is true.
# Rules are processed in the order they appear.

[processor "a"]
match = foo.*

[processor "b"]
match = bar.*

[processor "default"]
match = .*

Original issue reported on code.google.com by [email protected] on 25 Feb 2015 at 10:36

[GoogleCodeExporter]

Thanks for the feedback! I understand how having ordered structs would 
potentially make it easier to use for some use cases. But at the same time I'm 
hesitant to introduce order-dependency for subsections, as it feels somewhat 
inconsistent (sections and variables in sections are order-independent) and may 
not work well with other (planned) features, such as multi-file support which 
is also a common need (and already kind of supported by calling ReadFileInto 
consecutively with different files).

Consider for example what if one file defines processors "a" and "b" in that 
order, and then another file (re)defines/overrides processors in the order "c" 
"b" "a" (or just "c" "a"). Does it only override the values inside "a" and "b" 
or does it also override the order (and should it drop "b" in the latter case)? 
I think going either way would confuse many users, and that it's better to have 
the precedence listed explicitly rather than implied by the order in file.

Currently the only place where order is maintained is for multi-valued 
variables. So for the current version, I'd suggest to add a new variable 
somewhere with the list of names, e.g.

[processors]
processor = a
processor = b
processor = default

[processor "a"]
match = foo.*
...

It is a bit more typing, but it makes the order explicit, and more consistent 
with existing and planned features. It also makes reordering easier.

Another variation (which requires a bit of value parsing) is to do something 
like this, similarly to how git-config handles proxy configuration:

[routing]
processor = a for foo.*
processor = b for bar.*
processor = default

[processor "a"]
...

This decouples routing (when to use which processor) from the processor itself 
(i.e. what the processor does), which can be useful in some contexts (but not 
sure if it is useful in your case). In addition it also allows multiple routing 
entries with different patterns to share the same processor (again, you may not 
need this).

Your use case also seems somewhat related to issue 10 which also relates to 
ordered subsections (which I closed at the time because it seemed too niche). 
For future enhancement, one possibility could be to add subsections with 
integer keys (stored in an array/slice with the key as the index):

[processor 0]
name = a
match = foo.*
...

This seems to be a good solution in case there is a fixed number of items and 
there is no need for inserting / reordering (like in issue 10), but I got the 
impression that reordering / inserting could occur in your case, which makes 
using numbers cumbersome due to the need for renumbering. Still if you think it 
would be useful in your use case, let me know, and I'll consider it as a vote 
towards adding this feature.

Original comment by [email protected] on 26 Feb 2015 at 11:02