Re: 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: Well since the caller is handling a string, shouldn't the caller verify the content before any conversion? What if: "1.1.1".to!int ? The algorithm will become more complicated? Will the speed decrease?
Re: 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.
Re: is type checking in D undecidable?
On Friday, 23 October 2020 at 16:56:46 UTC, Kagamin wrote: On Thursday, 22 October 2020 at 18:24:47 UTC, Bruce Carneal wrote: Per the wiki on termination analysis some languages with dependent types (Agda, Coq) have built-in termination checkers. What they do with code that does, say, a hash preimage attack? Not my area but after a quick wiki skim my guess is that the termination checkers would not be helpful at all. If you do pick up one of the termination checker languages and experiment, please post back with the results.
Re: mysql-native Help required
On Thursday, 22 October 2020 at 18:43:40 UTC, Steven
Schveighoffer wrote:
On 10/22/20 11:00 AM, Vino wrote:
[...]
Different error:
Row[] data = conn.query("SELECT * FROM hostlog").array;
This is trying to call mysql-native's UFCS query function on
Connections, which isn't valid. You need to call it on
conn.conn.
But there's no access to the private Connection conn inside the
Connections class. I'm not sure what the class is for anyway,
so it's hard for me to suggest a proper alternative. Are you
just trying to encapsulate the connection string? I'd suggest
instead of a whole class, just a factory function:
Connection getConnection()
{
return new Connection("...");
}
-Steve
Was about to say that. Part of why I think some people hate
OOP...due to misuse.
All my MySQL projects have this getConnection() function.
Re: is type checking in D undecidable?
On Thursday, 22 October 2020 at 18:24:47 UTC, Bruce Carneal wrote: Per the wiki on termination analysis some languages with dependent types (Agda, Coq) have built-in termination checkers. What they do with code that does, say, a hash preimage attack?
Re: Question about: ("1.1").to!int;
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.
Can we do compile time reading part of a file using import?
Hi all, the `import` function allows a file to be read at compile time, which opens up great opportunities for (mostly binary) file IO, where data types can be coded into files - the user doesn't need to know data types ahead of time. As specified in my old blog article: https://www.active-analytics.com/blog/reading-idx-files-in-d/. Binary files can be very large and reading the whole file at compile time is often unnecessary. This isn't exactly the intended use for the function, but there it is. Since compile time read capability already exists and is useful, adding capability to be able to read only a portion of the file at compile time in a given location is advantageous and has utility. For me it's not make-or-break, it just something very useful and I think has clear use case. Please let me know if there are aspects or alternatives I am missing. Thanks
Re: Question about: ("1.1").to!int;
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.
Re: Question about: ("1.1").to!int;
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"));
}
Re: Question about: ("1.1").to!int;
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.
Re: Question about: ("1.1").to!int;
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.
Re: Question about: ("1.1").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.
Re: Question about: ("1.1").to!int;
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.
