splitter for strings

[Steven Schveighoffer via Digitalmars-d-learn]

On Mon, 09 Jun 2014 12:06:13 -0400, monarch_dodra <monarchdodra at gmail.com>  
wrote:

> On Monday, 9 June 2014 at 15:54:29 UTC, Steven Schveighoffer wrote:
>> On Mon, 09 Jun 2014 11:49:29 -0400, monarch_dodra  
>> <monarchdodra at gmail.com> wrote:
>>
>>> On Monday, 9 June 2014 at 14:21:21 UTC, Steven Schveighoffer wrote:
>>>> Just looked at std.string for a strip function that allows custom  
>>>> character strippage, but apparently not there. The above is quite  
>>>> awkward.
>>>>
>>>> -Steve
>>>
>>> It's in algorithm, because it's more generic than just strings.
>>
>> Ugh.. This makes things difficult. If I want to work with strings, I  
>> import std.string.
>>
>> I understand that the algorithm is applicable to all types, but this  
>> makes for some awkward coding. What if you wanted to use both? Surely  
>> we can come up with a better solution than this.
>>
>> -Steve
>

I think we are confusing things here, I was talking about strip :)


> There's 2 different issues: The first, is that "split(string)" was  
> pre-existing in std.string, and *then* split was introduced in  
> algorithm. Where ideally (?) everything would have been placed in the  
> same module, we true to avoid moving things around now.
>
> The second thing is that "split" without any predicate/item can only  
> make sense for strings, but not for generic ranges.
>
> For what it's worth, I find it makes sense.

Well, I suppose it should probably work if you try both strip and  
strip('-')...

and indeed it does. It is not as bad as I thought (I thought they would  
conflict).

It still leaves me a bit uneasy that std.string does not provide  
everything you would need to work with strings. But we don't want  
std.string importing std.algorithm, or at least we don't want it importing  
ALL of std.algorithm.

If we could split up std.algorithm into individual modules, that would  
probably help.

-Steve