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 strings efficiently and correctly (split, find, etc...). Things only start getting funny once you start mixing indexing and element counts.

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 getting funny once you start mixing indexing and element counts.

If the recommended approach for writing a really trivial string transformation is to copy and modify ~60 lines of std lib code then something is very wrong. The consequence is that such code will often end up being eager, as it's much easier to write it that way... That is why, after seeing your solution, I wrote the most compact lazy version I could think of - let's not scare people away from using ranges.

AFAIUI the OP basically wanted a version of splitter that does not eat the separators and a predicate that keeps around previous state. The latter can already be achieved via a lambda, so the missing bit is an optional splitter template parameter (eg consume=false). So at least in this case the problem could be easily handled.

artur

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, Range)(input);
> }
> ...

Your solution copied here

https://github.com/nordlow/justd/blob/master/slicer.d

errors as
/home/per/opt/x86_64-unknown-linux-gnu/dmd/linux/bin64/src/phobos/std/algorithm.d(5752,24): Error: template std.functional.not!(isUpper).not cannot deduce function from argument types !()(dchar), candidates are:
/home/per/opt/x86_64-unknown-linux-gnu/dmd/linux/bin64/src/phobos/std/functional.d(393,10):        std.functional.not!(isUpper).not(T...)(T args) if (is(typeof(!unaryFun!pred(args))) || is(typeof(!binaryFun!pred(args))))
slicer.d(29,31): Error: template instance std.algorithm.find!(not, string) error instantiating
slicer.d(16,12):        instantiated from here: Slicer!(isUpper, string)
slicer.d(85,30):        instantiated from here: slicer!(isUpper, string)

What's wrong?

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(input.front))))
>> {
>>    return SlicerResult!(unaryFun!isTerminator, Range)(input);
>> }
>> ...
>
> Your solution copied here
>
> https://github.com/nordlow/justd/blob/master/slicer.d
>
> errors as
> /home/per/opt/x86_64-unknown-linux-gnu/dmd/linux/bin64/src/phobos/std/algorithm.d(5752,24): Error: template std.functional.not!(isUpper).not cannot deduce function from argument types !()(dchar), candidates are:
> /home/per/opt/x86_64-unknown-linux-gnu/dmd/linux/bin64/src/phobos/std/functional.d(393,10):
>        std.functional.not!(isUpper).not(T...)(T args) if (is(typeof(!unaryFun!pred(args))) || is(typeof(!binaryFun!pred(args))))
> slicer.d(29,31): Error: template instance std.algorithm.find!(not, string) error instantiating
> slicer.d(16,12):        instantiated from here: Slicer!(isUpper, string)
> slicer.d(85,30):        instantiated from here: slicer!(isUpper, string)
>
> What's wrong?

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 what unaryFun is.

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 what unaryFun is.

I don't understand. The restraints are commented out at

https://github.com/nordlow/justd/blob/master/slicer.d

I made a couple of changes and now it works but I don't quite understand why...

Thanks anyway.

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 the typeof fails is simply cause the compiler has no idea what unaryFun is.
>
> I don't understand. The restraints are commented out at
>
> https://github.com/nordlow/justd/blob/master/slicer.d
>
> I made a couple of changes and now it works but I don't quite understand why...
>
> Thanks anyway.

Sorry, I read your compile error wrong, and was on my phone.

Anyways, I'm a bit worried, because it looks like an internal phobos compile error. May I request you attempt to re-create and potentially reduce the issue? I want to make sure you didn't uncover a bug...