Consider the following code

---------
import std.range;
import std.conv;
import std.utf;
import std.algorithm;

auto test(R)(R s)
{
    auto value = s.byCodeUnit;
    auto splitValue = value.splitter('.');
    parse!int(splitValue.front);
}

void main()
{
    test("1.8");
}
---------

This fails to compile and I can't for the life of me understand why. The std.conv.parse call doesn't match any parse overload when it should match the second one:

---------
std.conv.parse(Target, Source)(ref Source s) if (
    isSomeChar!(ElementType!Source) && isIntegral!Target && !is(Target == enum))
---------

Manually verifying the template constraints proves that it should work,

---------
pragma(msg, isSomeChar!(ElementType!(typeof(splitValue.front))), isIntegral!int, !is(int == enum));

truetruetrue
---------

Any help here would be appreciated.

On 05/24/2016 03:59 AM, Jack Stouffer wrote:
>      parse!int(splitValue.front);
[...]
> std.conv.parse(Target, Source)(ref Source s) if (
>      isSomeChar!(ElementType!Source) && isIntegral!Target && !is(Target
> == enum))

You're missing that `parse`'s parameter is `ref`. `splitValue.front` is not an lvalue, so it can't be passed in a ref parameter.

This works:
----
    auto f = splitValue.front;
    parse!int(f);
----

On Tuesday, 24 May 2016 at 05:01:39 UTC, ag0aep6g wrote:
> You're missing that `parse`'s parameter is `ref`. `splitValue.front` is not an lvalue, so it can't be passed in a ref parameter.
>
> This works:
> ----
>     auto f = splitValue.front;
>     parse!int(f);
> ----

Thanks. DMD desperately needs better error messages :/

On Tuesday, 24 May 2016 at 05:01:39 UTC, ag0aep6g wrote:
> You're missing that `parse`'s parameter is `ref`.

Do you what the rationale behind this is? I just removed the ref from the floating point from input range overload and it works fine for strings.

On 5/25/16 11:15 AM, Jack Stouffer wrote:
> On Tuesday, 24 May 2016 at 05:01:39 UTC, ag0aep6g wrote:
>> You're missing that `parse`'s parameter is `ref`.
>
> Do you what the rationale behind this is? I just removed the ref from
> the floating point from input range overload and it works fine for strings.

parse consumes data from the string as it goes.

If you want to leave the data there, use to instead.

-Steve

On Wednesday, 25 May 2016 at 15:34:45 UTC, Steven Schveighoffer wrote:
> parse consumes data from the string as it goes.

I know that, I'm asking why. This disallows the natural range chaining and forces you to save to a variable before calling parse even though the function works just as well without it.

> If you want to leave the data there, use to instead.

Can't without calling std.array.array.

On 5/25/16 12:10 PM, Jack Stouffer wrote:
> On Wednesday, 25 May 2016 at 15:34:45 UTC, Steven Schveighoffer wrote:
>> parse consumes data from the string as it goes.
>
> I know that, I'm asking why. This disallows the natural range chaining
> and forces you to save to a variable before calling parse even though
> the function works just as well without it.

If parse returned the leftover string, and took the data to parse as the ref parameter, then it doesn't fit into other use cases.

>> If you want to leave the data there, use to instead.
>
> Can't without calling std.array.array.

Is there a specific use case that doesn't work? to should work wherever parse works (in fact, whenever you call to!someType(someString), I believe it just forwards to parse).

-Steve

On Wednesday, 25 May 2016 at 16:53:30 UTC, Steven Schveighoffer wrote:
> to should work wherever parse works (in fact, whenever you call to!someType(someString), I believe it just forwards to parse).

This is not the case; to doesn't work with ranges:

    auto str = "1234567".byCodeUnit;
    auto result = parse!int(str);
    auto result2 = to!int(str); // doesn't compile

On 5/25/16 2:23 PM, Jack Stouffer wrote:
> On Wednesday, 25 May 2016 at 16:53:30 UTC, Steven Schveighoffer wrote:
>> to should work wherever parse works (in fact, whenever you call
>> to!someType(someString), I believe it just forwards to parse).
>
> This is not the case; to doesn't work with ranges:
>
>      auto str = "1234567".byCodeUnit;
>      auto result = parse!int(str);
>      auto result2 = to!int(str); // doesn't compile
>

If parse can do it, to should as well.

I think it's a question of how the template constraints are done. Please file an issue.

-Steve

On Wednesday, 25 May 2016 at 18:43:05 UTC, Steven Schveighoffer wrote:
> If parse can do it, to should as well.
>
> I think it's a question of how the template constraints are done. Please file an issue.

Found this: https://issues.dlang.org/show_bug.cgi?id=15800