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.
