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

From: Junio C Hamano <[email-masked]>
Date: Tue, 01 Jul 2014 10:45:19 -0700

Jeff King <[email-masked]> 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 <[email-masked]>
> ---
> 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?