Hi Junio,

On Mon, 8 Aug 2016, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > I wonder, however, if we could somhow turn things around by
> > introducing something like
> >
> > 	split_and_do_for_each(item_p, length, string, delimiter)
> > 		... <do something with item_p and length> ...
> >
> > that both string_list_split() *and* add_strategies() could use? We
> > would then be able to avoid allocating the list and duplicating the
> > items in the latter case.
> 
> I do think such a feature may be useful if we often work on pieces of a
> string delimited by a delimiter, but if the caller does not see the
> split result, then the function with "split" is probably misnamed.
> 
> I however suspect the variant of this where "delimiter" can just be a
> single byte would not be so useful.
> 
> If the input comes from the end user, we certainly would want to allow
> "word1  word2\tword3 " as input (i.e. squishing repeated delimiters into
> one without introducing an "empty" element, allowing more than one
> delimiter characters like SP and HT, and ignoring leading or trailing
> runs of delimiter characters).
> 
> If the input is generated internally, perhaps we should rethink the
> interface between the function that wants to do the for-each-word and
> its caller; if the caller wants to pass multiple things to the callee,
> it should be able to do so without first having to stuff these multiple
> things into a single string, only to force the callee to use this helper
> to split them out into individual pieces.

All true, but I guess this type of complexity would really complexify
René's patch too much, so I am comfortable with the patch as-is.

Ciao,
Dscho