replaceFirst, findPieces, and takeExactly

[Andrei Alexandrescu]

On 1/22/11 5:41 PM, Tomek Sowiński wrote:
> 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.

Lazy in this case is not very helpful because you don't have the 
lengths. Turns out it's important to have the length. If not, you can 
always use until().

Andrei