Question about: ("1.1").to!int;

[Виталий Фадеев]

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.