replaceFirst, findPieces, and takeExactly

[Tomek Sowiński]

Andrei Alexandrescu napisał:

> 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.

Me a tad less, but not because of the name. I'd still rather see a lazy range of pre-hit-post tuples. Am I the only one to see findParts as a no-patterns variation of RegexMatch accepting all element types, not just char? Then even the name comes naturally -- match.

-- 
Tomek