Re: [PATCH 5/8] string-list: add pos to iterator callback

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> When we are running a string-list foreach or filter, the
> callback function sees only the string_list_item, along with
> a void* data pointer provided by the caller. This is
> sufficient for most purposes.
>
> However, it can also be useful to know the position of the
> item within the string (for example, if the data pointer

s/the string/&-list/ (or s/&/&_list/).

> points to a secondary array in which each element
> corresponds to part of the string list). We can help this
> use case by providing the position to each callback.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> The diff here is noisy, and I expect in the long run that the one caller
> I add to builtin/tag.c later in the series will eventually stop using
> string_list entirely (in favor of a custom struct), which may leave us
> with no callers that actually use the new field.
>
> I do think the logic above is sound, though, and it's a potentially
> useful thing. There may be other sites that avoid the for_each wrapper
> in favor of iterating themselves simply _because_ they needed to know
> the position (I would just do the same here, except that my new caller
> wants to use filter_string_list, which is a little more complicated).

While I can buy that some callers would want to learn the pos in the
list, I am not sure if this is a good direction to go.  Primarily, I
am having trouble sifting between "want" and "need".

How often do callers want to do this?  If only narrow specialized
callers want this, is it unreasonable to ask them to add a "int ctr"
in their cb_data and use "pos = ((struct theirs *)cb_data)->ctr++"
in their callback instead?