Jeff King <peff@xxxxxxxx> 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@xxxxxxxx> > --- > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html