splitter for strings

[Chris via Digitalmars-d-learn]

On Monday, 9 June 2014 at 12:16:30 UTC, monarch_dodra wrote:
> On Monday, 9 June 2014 at 11:40:24 UTC, Chris wrote:
>> On Monday, 9 June 2014 at 11:16:18 UTC, monarch_dodra wrote:
>>> On Monday, 9 June 2014 at 11:04:12 UTC, Chris wrote:
>>>> From the library reference:
>>>>
>>>> assert(equal(splitter("hello  world", ' '), [ "hello", "", 
>>>> "world" ]));
>>>>
>>>> and
>>>>
>>>> "If a range with one separator is given, the result is a 
>>>> range with two empty elements."
>>>>
>>>> My problem was that if I have input like
>>>>
>>>> auto word = "bla-";
>>>>
>>>> it will return parts.data.length == 2, so I would have to 
>>>> check parts.data[1] != "". This is too awkward. I just want 
>>>> the parts of the word, i.e.
>>>>
>>>> length == 2 // grab [0] grab [1]
>>>> length == 1 // grab [0] (no second part, as in "bla-")
>>>> length > 2 // do something else
>>>
>>> You can just pipe in an extra "filter!(a=>!a.empty)", and 
>>> it'll do what you want:
>>> put(parts, w.splitter('-').filter!(a=>!a.empty)());
>>>
>>> The rational for this behavior, is that it preserves the 
>>> "total amount of information" from your input. EG:
>>>
>>> assert(equal(myString.spliter(sep).join(sep), myString));
>>>
>>> If the empty tokens were all stripped out, that wouldn't 
>>> work, you'd have lost information about how many separators 
>>> there actually were, and where they were.
>>
>> I see, I've already popped in a filter. I only wonder how much 
>> of a performance loss that is. Probably negligible.
>
> Arguably, none, since someone has to do the check anyways. If 
> it's not done "outside" of splitter, it has to be done inside...

Yes, of course. I just thought if it's done in the library 
function, the optimization might be better than when it is done 
in my code. (filter!() is arguably also in the library :)