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
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
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
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
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?
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
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:
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
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
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
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
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 =
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; //
13 matches
Mail list logo
