On Friday, 10 October 2014 at 05:55:00 UTC, Nordlöw wrote:
On Thursday, 9 October 2014 at 22:01:31 UTC, monarch_dodra
wrote:
My quick guess is you are missing the *global* imports for the
restraints. The compiler doesn't complain because the
constraint is in a is(typeof(...)) test. The reason
On Wednesday, 11 June 2014 at 08:58:58 UTC, monarch_dodra wrote:
auto slicer(alias isTerminator, Range)(Range input)
if (((isRandomAccessRange!Range hasSlicing!Range) ||
isSomeString!Range)
is(typeof(unaryFun!isTerminator(input.front
{
return SlicerResult!(unaryFun!isTerminator,
On Thursday, 9 October 2014 at 21:55:03 UTC, Nordlöw wrote:
On Wednesday, 11 June 2014 at 08:58:58 UTC, monarch_dodra wrote:
auto slicer(alias isTerminator, Range)(Range input)
if (((isRandomAccessRange!Range hasSlicing!Range) ||
isSomeString!Range)
On Thursday, 9 October 2014 at 22:01:31 UTC, monarch_dodra wrote:
My quick guess is you are missing the *global* imports for the
restraints. The compiler doesn't complain because the
constraint is in a is(typeof(...)) test. The reason the
typeof fails is simply cause the compiler has no idea
On Tuesday, 10 June 2014 at 22:31:37 UTC, Nordlöw wrote:
Either way, it shouldn't be too hard to implement. Base it off
splitter!pred, which is actually quite trivial. AFAIK, your
What do you mean by basing it off splitter!pred - should I
start with some existing splitter algorithm in Phobos
On 06/11/14 00:31, Nordlöw via Digitalmars-d-learn wrote:
Either way, it shouldn't be too hard to implement. Base it off
splitter!pred, which is actually quite trivial. AFAIK, your
What do you mean by basing it off splitter!pred - should I start with some
existing splitter algorithm in
On Wednesday, 11 June 2014 at 11:42:42 UTC, Artur Skawina via
Digitalmars-d-learn wrote:
On 06/11/14 00:31, Nordlöw via Digitalmars-d-learn wrote:
Either way, it shouldn't be too hard to implement. Base it
off splitter!pred, which is actually quite trivial. AFAIK,
your
What do you mean by
On 06/11/14 14:40, monarch_dodra via Digitalmars-d-learn wrote:
For example, you should avoid countUntil and takeExactly when dealing
with strings, since these are not O(1) operations, and don't actually return
string slices. EG:
string s = someGGGreatVariableName.slicer().front;
Error:
On 06/11/14 15:44, Artur Skawina wrote:
If, instead, you create a string-specific 'countUntil' that returns
a type that holds both the byte and code-point counts and implicitly
converts to the latter, then you can have a 'takeExactly' overload
that uses the extra info to avoid the unnecessary
On Wednesday, 11 June 2014 at 13:44:25 UTC, Artur Skawina via
Digitalmars-d-learn wrote:
There is a reason why I never use D's std lib.
artur
Well, (IMO) it's a problem with no real solution. But for what
it's worth, most (if not all) of the algorithms in the standard
lib know how to handle
On 06/11/14 16:05, monarch_dodra via Digitalmars-d-learn wrote:
Well, (IMO) it's a problem with no real solution. But for what it's worth,
most (if not all) of the algorithms in the standard lib know how to handle
strings efficiently and correctly (split, find, etc...). Things only start
I'm missing a version of splitter that can be used to split
ranges based on arbitrary predicates. I need to for conversion
between different symbol casings, typically:
1. someName = SomeName
In this case the lambda should take two arguments (a,b)
where in
1. a should be lowercase and b
1. someName = SomeName
My example is dumb and incorrect.
I actually want this to do the following
2. _someGreatVariableName = Some Great Varible Name
On Tuesday, 10 June 2014 at 21:11:17 UTC, Nordlöw wrote:
1. someName = SomeName
My example is dumb and incorrect.
I actually want this to do the following
2. _someGreatVariableName = Some Great Varible Name
The current splitter works on the notion of splitter tokens,
eg, it splits when it
On Tuesday, 10 June 2014 at 21:26:50 UTC, monarch_dodr
What exactly are you requesting though?
- Split on the edge lowercase to uppercase?
- Split on uppercase but keep the uppercase element?
Thinking about this more: Do you *actually* have two different
predicates, or are they mutually
Either way, it shouldn't be too hard to implement. Base it off
splitter!pred, which is actually quite trivial. AFAIK, your
What do you mean by basing it off splitter!pred - should I start
with some existing splitter algorithm in Phobos or start from
scratch?
Thx.
16 matches
Mail list logo
