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 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 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)
&& is(typeof(unaryFun!isTerminator(inp
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!isTerminato
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
>
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 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 unnecessa
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;
>
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 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 algori
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
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.
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 excl
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
1. someName => SomeName
My example is dumb and incorrect.
I actually want this to do the following
2. "_someGreatVariableName" => "Some Great Varible Name"
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 shou
16 matches
Mail list logo
