www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - std.conv.parse not accepting ByCodeUnitImpl

reply Jack Stouffer <jack jackstouffer.com> writes:
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.
May 23 2016
parent reply ag0aep6g <anonymous example.com> writes:
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);
----
May 23 2016
next sibling parent Jack Stouffer <jack jackstouffer.com> writes:
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 :/
May 24 2016
prev sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
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.
May 25 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
May 25 2016
parent reply Jack Stouffer <jack jackstouffer.com> writes:
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.
May 25 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
May 25 2016
parent reply Jack Stouffer <jack jackstouffer.com> writes:
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
May 25 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
May 25 2016
parent Jack Stouffer <jack jackstouffer.com> writes:
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
May 25 2016