On Mon, 09 Jun 2014 12:06:13 -0400, monarch_dodra <monarchdo...@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
<monarchdo...@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
