replaceFirst, findPieces, and takeExactly

[Jonathan M Davis]

On Saturday 22 January 2011 15:19:39 Andrei Alexandrescu wrote:
> On 1/22/11 5:14 PM, Nick Sabalausky wrote:
> > "Andrei Alexandrescu"<SeeWebsiteForEmail at erdani.org>  wrote in message
> > news:ihfm34$jvb$1 at digitalmars.com...
> > 
> >> On 1/22/11 4:16 PM, bearophile wrote:
> >>> Andrei:
> >>>> Back then people said that STL's find() is better than D's find()
> >>>> because the former returns
> >>>> an iterator that can be combined with either the first iterator to get
> >>>> the portion before the match, or with the last iterator to get the
> >>>> portion starting at the match. D's find() only gives you the portion
> >>>> after the match.
> >>> 
> >>> There's a HUGE problem here. This equivalence is sometimes true, but
> >>> surely not always true:
> >>> "more powerful" != "better"
> >>> 
> >>>> That function allows you to pick a determined number of elements from
> >>>> a range, assuming the range is never shorter than that. That sounds a
> >>>> bit obscure, but plays a pivotal role in findParts() (which is the
> >>>> name I
> >>> 
> >>>> settled on for the equivalent of Python's partition()):
> >>> "trisect" is way better than "findParts" :-) And it's a single word
> >>> with no uppercase letters in the middle.
> >> 
> >> There is still time until the next release. Votes for trisect?
> > 
> > vote--
> > 
> > "findParts" is the sort of thing that once you read what it does just
> > *once*, it immediately becomes both obvious and easy to remember. But
> > "trisect" is 1. scary, 2. I'd never remember it, and 3. Whenever I'd come
> > across it, I'd never remember what it meant.  Those are paricularly bad
> > since I know right now I'm going to find it an incredibly useful
> > function: There's already been too many times I've written this mess and
> > felt dirty about it:
> > 
> > auto result = find(str, delim);
> > auto firstPart = str[0..$-result.length];
> > 
> > So I'm thrilled to see this function being added.
> 
> Yes, I'm absolutely in agreement with the naming (and thrilled too). I
> imagine a putative user looking through std.algorithm ("let's see...
> what find functions are out there?"). That makes findPieces easy to get
> to, whereas "trisect" would be oddly situated in the alphabetic list and
> oddly named enough to be virtually undiscoverable.

++++++++++++++++++++++++++++++++vote

This will be a _fantastic_ function to have. I think that I probably even have 
an enhancement request somewhere that includes such a function. It's far too 
common that you have to find something and you want both what is before and after 
the point that you find. Now, that being the case, I'd probably more commonly find 
it useful to get the part before what was found and then the part beginning with 
what was found, but this works too.

It is essentially doing what find does, only giving you more stuff in the result, 
so I do think that it fits well with find, and having its name starting with find 
means that it will be near find in the documentation, which will make it much 
easier to find (no pun intended - though I do like puns). The term findParts 
doesn't really say what the function does (which parts are you looking for, 
after all?), but it _is_ a name which will be memorable, and once you've read 
the docs, it will be plenty clear what it does. I certainly can't think of a 
better name, and I definitely prefer it over the other names that I'm seeing 
suggested in this thread.

- Jonathan M Davis