0 < negative loop condition bug or misunderstanding on my part

[Jonathan M Davis]

On Wednesday, March 07, 2012 13:20:41 Sean Cavanaugh wrote:
> On 3/7/2012 12:57 PM, Jonathan M Davis wrote:
> > On Wednesday, March 07, 2012 11:01:05 Timon Gehr wrote:
> >> On 03/07/2012 07:05 AM, ixid wrote:
> >>> Ah, thank you, so it's wrapping. That seems like a bad idea, what is the
> > 
> > I suspect that the reality of the matter is that if we disallowed implicit
> > conversions between signed and unsigned, a number of bugs would completely
> > go away, but others would creep in as a result, and the overal situation
> > wouldn't necessarily be any better, but I don't know. My initial reaction
> > would be to agree with you, but there are definitely cases where such an
> > approach would get annoying and bug-prone (due to the casting involved).
> > But regardless, I really don't think that you're going to convince Walter
> > on this one, given what he's said in the past.
> > 
> > - Jonathan M Davis
> 
> After writing enough container libraries and whatnot in C++, I always
> end up going bed while thinking life would be so much easier if implicit
> signed/unsigned conversions were not allowed.
> 
> Then I go to sleep, wake up, and realize how much more horrific the code
> would be in other places if this was actually true.
> 
> The best compromise would probably have been to make size_t signed when
> migrating to 64 bit memory addressing, and leave the unsigned/signed
> problems specificaly with size_t values back in the past of 32 bit and
> older systems.
> 
> 
> On a related note I would love to see something in std.somewhere (conv?)
> to provide a complete set of narrowing and signed/unsigned conversion
> functions: The matrix is basically the following methods:
> 1) Reduce size (64->32->16->8 bits) but maintain signedness with three
> types:
> 2) Methods to flip signedness of the value (but mainting bitwidth)
> 
> 
> multiplied against three types of operations:
> a) truncating (i.e. mask off the lower bits)
> b) saturating (values outside of range are clamped to min or max of the
> narrower range)
> c) throwing (values outside of narrow range throw a range exception)

std.conv.to will check non-implicit, narrowing conversions to make sure that 
the number will fit in the new type (throwing a ConvException if it won't), but 
if you're converting between types of the same size but which differ in 
signedness, then that's an implicit conversion, at it's the same as if you 
didn't use std.conv.to at all.

- Jonathan M Davis