On Friday, March 29, 2013 17:27:10 Minas Mina wrote:
> Consider:
> uint u = ...;
> int x = u;
> 
> Wouldn't a warning be enough?

No. -w makes it so that warnings are errors, so you generally can't make anything a warning unless you're willing for it to be treated as an error at least some of the time (and a lot of people compile with -w), and this sort of thing is _supposed_ to work without a warning - primarily because if it doesn't, you're forced to cast all over the place when you're dealing with both signed and unsigned types, and the casts actually make your code more error-prone, because you could end up casting something other than uint to int or int to uint by accident (e.g. long to uint) and end up with bugs due to that.

There are definitely cases where it would be nice to warn about conversions between signed and unsigned values, but there's a definite cost to it as well, so the situation is not at all clear cut.

- Jonathan M Davis

Am 29.03.2013 20:29, schrieb Jonathan M Davis:
> No. -w makes it so that warnings are errors, so you generally can't make
> anything a warning unless you're willing for it to be treated as an error at
> least some of the time (and a lot of people compile with -w), and this sort of
> thing is _supposed_ to work without a warning - primarily because if it
> doesn't, you're forced to cast all over the place when you're dealing with
> both signed and unsigned types, and the casts actually make your code more
> error-prone, because you could end up casting something other than uint to int
> or int to uint by accident (e.g. long to uint) and end up with bugs due to
> that.

Reading this tells me two things:

1) The D-Cast is seriously broken, the default behavior should not be one that "breaks" stuff if you don't use it right. I personally really like the idea of having different types of casts. Some of which still doe checks and other that just do what you want because you know what yu are doing.
2) The library needs something like an int_cast which checks casts from one integer type to another and asserts / throws on error. (For an example see https://github.com/Ingrater/thBase/blob/master/src/thBase/casts.d#L28)

Kind Regards
Benjamin Thaut

On Friday, 29 March 2013 at 19:38:32 UTC, Benjamin Thaut wrote:

> 2) The library needs something like an int_cast which checks casts from one integer type to another and asserts / throws on error.

uint value = 3408924;
auto v = std.conv.to!int(value);

Exception is thrown if an overflow occurs.

> If you remove the implicit uint==>int assignment from D you have to add many cast() in the code. And casts are dangerous, maybe even more than implicit casts.

On the other hand I have not tried D with such change, so that's
just an hypothesis. And maybe a library-defined
toSigned()/toUnsigned() are enough here.

Bye,
bearophile

On Friday, 29 March 2013 at 19:29:21 UTC, Jonathan M Davis wrote:
> because if it
> doesn't, you're forced to cast all over the place

There are so many implicit conversions between signed and unsigned? Are they all ok?

Kagamin:

> Jonathan M Davis wrote:
>> because if it
>> doesn't, you're forced to cast all over the place
>
> There are so many implicit conversions between signed and unsigned? Are they all ok?

I think Jonathan doesn't have enough proof that forbidding signed<->unsigned implicit casts in D is worse than the current situation that allows them.

Bye,
bearophile

On Saturday, March 30, 2013 22:12:30 bearophile wrote:
> Kagamin:
> > Jonathan M Davis wrote:
> >> because if it
> >> doesn't, you're forced to cast all over the place
> > 
> > There are so many implicit conversions between signed and unsigned? Are they all ok?
> 
> I think Jonathan doesn't have enough proof that forbidding signed<->unsigned implicit casts in D is worse than the current situation that allows them.

Walter is the one that you have to convince, and I don't think that that's ever going to happen.

- Jonathan M Davis

Jonathan M Davis:

> Walter is the one that you have to convince, and I don't think that that's ever going to happen.

I understand. But maybe Walter too don't have that proof... I compile C code with all warnings, and the compiler tells me most cases of mixing signed with unsigned. I usually remove most of them.

I think the Go language doesn't have that implicit cast and Go programmers seem able to survive.

Bye,
bearophile

I vaguely remember Walter said those diagnostics are mostly false positives. Though I don't remember whether if was about implicit conversions.

I can say C compilers bug me with InterlockedIncrement function: it can be called on both volatile and non-volatile variables so type qualification of argument can't always match that of parameter and the compiler complains. I found that silly.