Hi,

import std.stdio, std.conv;
void main(string[ ] args) {
    auto a = (1).to!int;     // this works
    auto b = ("1").to!int;   // this works
    auto c = (1.1).to!int;   // this works and c = 1
    auto d = ("1.1").to!int; // Doesn't work
}

The forth line gives me:

std.conv.ConvException@/usr/include/dlang/dmd/std/conv.d(1898): Unexpected '.' when converting from type string to type int
----------------
??:? pure @safe int std.conv.toImpl!(int, immutable(char)[]).toImpl(immutable(char)[]) [0x55de76d9b4d7]
??:? pure @safe int std.conv.to!(int).to!(immutable(char)[]).to(immutable(char)[]) [0x55de76d99a17]
??:? _Dmain [0x55de76d9986e]

Question:

Since (1.1).to!int = 1, shouldn't the string value ("1.1").to!int at least try to convert to float/double and then to int?

Because for what I see "to!int" converts from: int,real but in case of string only when it is a integer representation?

Matheus.

On Wednesday, 21 October 2020 at 22:50:27 UTC, matheus wrote:

> Since (1.1).to!int = 1, shouldn't the string value ("1.1").to!int at least try to convert to float/double and then to int?

I don't think so. A silent string->double conversion isn't IMO consistent with D's design.

"1.1".to!double.to!int works fine, and I like that you have to be explicit, because there is so much room for error.

Note that "1".to!double.to!int works as expected. Therefore you should be able to use that all the time.

On Wednesday, 21 October 2020 at 22:50:27 UTC, matheus wrote:
> Hi,
>
> import std.stdio, std.conv;
> void main(string[ ] args) {
>     auto a = (1).to!int;     // this works
>     auto b = ("1").to!int;   // this works
>     auto c = (1.1).to!int;   // this works and c = 1
>     auto d = ("1.1").to!int; // Doesn't work
> }
>
> [...]

1.1 is not int.
"to" works fine.

As solution,... "1.1" should be splitted to lexems: "1", ".", "1". Then analyze and then converted to int.

On Friday, 23 October 2020 at 08:09:13 UTC, Виталий Фадеев wrote:
> On Wednesday, 21 October 2020 at 22:50:27 UTC, matheus wrote:
>> Hi,
>>
>> import std.stdio, std.conv;
>> void main(string[ ] args) {
>>     auto a = (1).to!int;     // this works
>>     auto b = ("1").to!int;   // this works
>>     auto c = (1.1).to!int;   // this works and c = 1
>>     auto d = ("1.1").to!int; // Doesn't work
>> }
>>
>> [...]
>
> 1.1 is not int.
> "to" works fine.
>
> As solution,... "1.1" should be splitted to lexems: "1", ".", "1". Then analyze and then converted to int.

Of course 1.1 it's not an integer, but since (1.1).to!int works I thought that ("1.1").to!int should work too.

Matheus.

On Wednesday, 21 October 2020 at 22:50:27 UTC, matheus wrote:
> Since (1.1).to!int = 1, shouldn't the string value ("1.1").to!int at least try to convert to float/double and then to int?

The thing is, that's a great way for hard-to-identify bugs to creep into code.  In these cases:

    auto a = (1).to!int;     // this works
    auto b = ("1").to!int;   // this works
    auto c = (1.1).to!int;   // this works and c = 1

... then what the programmer wants is unambiguous.  In the first case it's just converting int => int.  In the second, it's converting from a string that unambiguously represents an integer value, to an int.  And in the third, it's converting _at programmer request_ from a double to an int (which has a well-defined behaviour).

However, if ("1.1").to!int were to work, this would be the `to` function making a judgement call on how to handle something ambiguous.  And while that judgement call may be acceptable for your current use-case, it won't be for others.

In particular, if `to` just accepted any string numerical representation for conversion to int, how could the caller explicitly _exclude_ non-integer input, if that is their use-case?

So it's far better to require you, as the programmer, to make what you want unambiguous and explicitly write code that will (i) deserialize any numerical string that is acceptable to you and (ii) convert to integer.

On Friday, 23 October 2020 at 13:57:41 UTC, Joseph Rushton Wakeling wrote:
> On Wednesday, 21 October 2020 at 22:50:27 UTC, matheus wrote:
>> Since (1.1).to!int = 1, shouldn't the string value ("1.1").to!int at least try to convert to float/double and then to int?
>
> The thing is, that's a great way for hard-to-identify bugs to creep into code.  In these cases:
>
>     auto a = (1).to!int;     // this works
>     auto b = ("1").to!int;   // this works
>     auto c = (1.1).to!int;   // this works and c = 1
>
> ... then what the programmer wants is unambiguous.  In the first case it's just converting int => int.  In the second, it's converting from a string that unambiguously represents an integer value, to an int.  And in the third, it's converting _at programmer request_ from a double to an int (which has a well-defined behaviour).
>
> However, if ("1.1").to!int were to work, this would be the `to` function making a judgement call on how to handle something ambiguous.  And while that judgement call may be acceptable for your current use-case, it won't be for others.
>
> In particular, if `to` just accepted any string numerical representation for conversion to int, how could the caller explicitly _exclude_ non-integer input, if that is their use-case?
>
> So it's far better to require you, as the programmer, to make what you want unambiguous and explicitly write code that will (i) deserialize any numerical string that is acceptable to you and (ii) convert to integer.

The third case is just like `cast(int) 1.1` it's not _at programmer request_ from my point of view, it's just that the `to` template has not be more restrictive than the D `cast` expression. `to` should do at least what a `cast` do and do more when there's no rule for the two types that are involved.

On Friday, 23 October 2020 at 13:57:41 UTC, Joseph Rushton Wakeling wrote:

> In particular, if `to` just accepted any string numerical representation for conversion to int, how could the caller explicitly _exclude_ non-integer input, if that is their use-case?
>
> So it's far better to require you, as the programmer, to make what you want unambiguous and explicitly write code that will (i) deserialize any numerical string that is acceptable to you and (ii) convert to integer.

Yes, that's the problem, and it doesn't make sense to use a statically typed language if the standard library silently introduces holes that lead to serious bugs (in this case, loss of numerical precision, which can be pretty nasty).

The solution is simple in this case, and it even leads to one less character when you're writing your program:

import std;
void main()
{
    int toInt(string s) {
        return(s.to!double.to!int);
    }

    writeln(toInt("1"));
    writeln(toInt("1.1"));
    writeln(toInt("a"));
}

On Friday, 23 October 2020 at 14:16:50 UTC, user1234 wrote:
> The third case is just like `cast(int) 1.1` it's not _at programmer request_ from my point of view

If the programmer explicitly writes a `to!int` or the `cast(int)`, then it's pretty clearly at their request.  And it's unambiguous what they are asking for.

But if the input to the conversion is a string, it's important that the conversion fail unless the string is an unambiguous representation of the intended destination type.  Otherwise, there is more than one data conversion going on, and one of them is being hidden from the programmer.

On Friday, 23 October 2020 at 13:57:41 UTC, Joseph Rushton Wakeling wrote:
> On Wednesday, 21 October 2020 at 22:50:27 UTC, matheus wrote:
>> Since (1.1).to!int = 1, shouldn't the string value ("1.1").to!int at least try to convert to float/double and then to int?
>
> The thing is, that's a great way for hard-to-identify bugs to creep into code.  In these cases:
>
>     auto a = (1).to!int;     // this works
>     auto b = ("1").to!int;   // this works
>     auto c = (1.1).to!int;   // this works and c = 1
>
> ... then what the programmer wants is unambiguous.  In the first case it's just converting int => int.  In the second, it's converting from a string that unambiguously represents an integer value, to an int.  And in the third, it's converting _at programmer request_ from a double to an int (which has a well-defined behaviour).
>
> However, if ("1.1").to!int were to work, this would be the `to` function making a judgement call on how to handle something ambiguous.  And while that judgement call may be acceptable for your current use-case, it won't be for others.

I got it everything you said, but like a said previously:

(1.1).to!int vs ("1.1").to!int

One is a decimal literal while the other is a string representation of a decimal.

To be honest I think the function is already making a judgment call when I do (1.1).to!int and returns 1, I really fail to see the difference when is ("1.1").to!int.

I agree with user1234: "The third case is just like `cast(int) 1.1` it's not _at programmer request_ from my point of view, it's just that the `to` template has not be more restrictive than the D `cast` expression. `to` should do at least what a `cast` do and do more when there's no rule for the two types that are involved."

> In particular, if `to` just accepted any string numerical representation for conversion to int, how could the caller explicitly _exclude_ non-integer input, if that is their use-case?

Well since the caller is handling a string, shouldn't the caller verify the content before any conversion?

Because a string may contain a integer, decimal representation or neither one.

Finally I don't want to make a fuss of it, I just thought it was a bit weird but it can be solved easily.

Thanks,

Matheus.

On Friday, 23 October 2020 at 16:59:06 UTC, matheus wrote:
> On Friday, 23 October 2020 at 13:57:41 UTC, Joseph Rushton Wakeling wrote:
>> On Wednesday, 21 October 2020 at 22:50:27 UTC, matheus wrote:
>>> Since (1.1).to!int = 1, shouldn't the string value ("1.1").to!int at least try to convert to float/double and then to int?
>>
>> The thing is, that's a great way for hard-to-identify bugs to creep into code.  In these cases:
>>
>>     auto a = (1).to!int;     // this works
>>     auto b = ("1").to!int;   // this works
>>     auto c = (1.1).to!int;   // this works and c = 1
>>
>> ... then what the programmer wants is unambiguous.  In the first case it's just converting int => int.  In the second, it's converting from a string that unambiguously represents an integer value, to an int.  And in the third, it's converting _at programmer request_ from a double to an int (which has a well-defined behaviour).
>>
>> However, if ("1.1").to!int were to work, this would be the `to` function making a judgement call on how to handle something ambiguous.  And while that judgement call may be acceptable for your current use-case, it won't be for others.
>
> I got it everything you said, but like a said previously:
>
> (1.1).to!int vs ("1.1").to!int
>
> One is a decimal literal while the other is a string representation of a decimal.
>
> To be honest I think the function is already making a judgment call when I do (1.1).to!int and returns 1, I really fail to see the difference when is ("1.1").to!int.
>
> I agree with user1234: "The third case is just like `cast(int) 1.1` it's not _at programmer request_ from my point of view, it's just that the `to` template has not be more restrictive than the D `cast` expression. `to` should do at least what a `cast` do and do more when there's no rule for the two types that are involved."
>
>> In particular, if `to` just accepted any string numerical representation for conversion to int, how could the caller explicitly _exclude_ non-integer input, if that is their use-case?
>
> Well since the caller is handling a string, shouldn't the caller verify the content before any conversion?
>
> Because a string may contain a integer, decimal representation or neither one.
>
> Finally I don't want to make a fuss of it, I just thought it was a bit weird but it can be solved easily.
>
> Thanks,
>
> Matheus.

For _execution speed_ reason we need low-level functions.
What if on each call ("1").to!int we will do parsing "1" for decimal point "." ?
.
Should be Low-level functions and High-level functions.
"to" is Low-level function.
.
You can create "To" function with parsing & validating.
You right: if "to" generating exception for non-numeric symbol, then it doing test each char... and "to" can just break loop at non-numeric symbol.
.
And...
.
"1".to!int
"1.1".to!int
"1abc".to!int
...they all can be == 1
.
Some like this:
foreach( c; str )
  if ( c.between( '0', '9' ) )
    result *= factor; result += ( c-'0' );
  else
    break;

.
You can write patch.