Jeff King <p...@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 <p...@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?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html