bearophile can say "i told you so" (re uint->int implicit conv)

[Don]

On Thursday, 28 March 2013 at 20:03:08 UTC, Adam D. Ruppe wrote:
> I was working on a project earlier today that stores IP 
> addresses in a database as a uint. For some reason though, some 
> addresses were coming out as 0.0.0.0, despite the fact that 
> if(ip == 0) return; in the only place it actually saves them 
> (which was my first attempted quick fix for the bug).
>
> Turns out the problem was this:
>
> if (arg == typeid(uint)) {
> 	int e = va_arg!uint(_argptr);
> 	a = to!string(e);
> }
>
>
> See, I copy/pasted it from the int check, but didn't update the 
> type on the left hand side. So it correctly pulled a uint out 
> of the varargs, but then assigned it to an int, which the 
> compiler accepted silently, so to!string() printed -blah 
> instead of bigblah... which then got truncated by the database, 
> resulting in zero being stored.
>
> I've since changed it to be "auto e = ..." and it all works 
> correctly now.
>
>
>
> Anyway I thought I'd share this just because one of the many 
> times bearophile has talked about this as a potentially buggy 
> situation, I was like "bah humbug"... and now I've actually 
> been there!
>
> I still don't think I'm for changing the language though just 
> because of potential annoyances in other places unsigned works 
> (such as array.length) but at least I've actually felt the 
> other side of the argument in real world code now.

IMHO, array.length is *the* place where unsigned does *not* work. 
size_t should be an integer. We're not supporting 16 bit systems, 
and the few cases where a size_t value can potentially exceed 
int.max could be disallowed.

The problem with unsigned is that it gets used as "positive 
integer", which it is not. I think it was a big mistake that D 
turned C's  "unsigned long" into "ulong", thereby making it look 
more attractive. Nobody should be using unsigned types unless 
they have a really good reason. Unfortunately, size_t forces you 
to use them.