Re: [PATCH 2/2] help: ensure &keys_uniq follows sort -u

>
> Amisha Chhajed <amishhhaaaa@gmail.com> writes:
>
> > From: Amisha Chhajed <136238836+amishhaa@users.noreply.github.com>
> >
> > uniqueness operation of &keys_uniq depends on the sort operation executed
> > for &keys this might introduce regressions in future when the logic of
> > forming &keys_uniq from &keys is changed.
> >
> > add string_list_sort_u operation for &keys_uniq after the processing of
> > &keys so it follows the expected sort -u behaviour.
>
> I am not sure the above reasoning is sound.  With the original code,
> we
>
>  - prepare empty keys_uniq
>  - collect keys
>  - sort keys
>  - iterate over keys
>    - add either the whole "section[.subsection].key" or "section" to keys_uniq
>
> before we call remove_duplicates.  keys_uniq would have duplicates,
> but because keys is sorted upfront, wouldn't the contents of
> keys_uniq be collected in sorted order anyway?

> This is not a performance critical part of the system, so it is OK
> as a future-proof measure to sort keys_uniq immediately before we
> start doing something that we _care_ about its sortedness (e.g.,
> presenting the final output to the user), even if keys_uniq is known
> to be already sorted with the current code.  Using sort_u here would
> allow us not to worry about how keys_uniq is constructed in that
> ugly loop.