<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Ok, I've come to the conclusion that we're never going to reach a
consensus, so I'll lay a card on the table. I never really liked
the change that makes implicit narrowing conversions illegal (or
most of the other increased strictness that D has acquired recently)
in the first place. This and many other things used to be a warning
and to me that's exactly what they should be. Warnings are for
things that are unambiguous, have a decent probability of not being
bugs, but also have a decent probability of being bugs. Errors are
for things that are ambiguous or are almost certainly bugs, or for
when you explicitly asked for extra checking, for example by using
const. You might want the compiler to complain about narrowing
conversions when you're trying to clean up the code, hunt for latent
bugs that would only show up in production, and get to the "make it
right" stage, or trying to figure out why it doesn't work. Most
narrowing conversions, though, are innocent and it's really annoying
for the compiler to act like they need to be addressed <b>right now</b>,
when you're still in the "make it work" stage or just writing some
quick and dirty piece of code that only needs to run once.<br>
<br>
On 2/17/2011 8:53 PM, Jonathan M Davis wrote:
<blockquote cite="mid:201102171753.24291.jmdavisProg@gmx.com"
type="cite"><br>
<pre wrap="">I concur. If you use auto and/or size_t, it's rarely a problem that size_t
changes its size based on the architecture. Using int or uint for indices is
generally wrong. If you really need it to be an int or uint, then a cast should
be used. And if you're really running into this problem all over the place,
because you frequently save array indices (which I would posit is _not_
something which is normally done very often, let alone in a manner that it would
be a problem just to save them as size_t), then you can create ilength in your
own code. But I really think that not only would ilength promote poor practices,
but it would generally lead to less maintainable code, because it would be
_really_ easy to mix up ilength and length.
And honestly, I would say the fact that someone is running into errors with
array indices in 64-bit land, because they weren't using size_t is just showing
that the code was faulty to begin with. They should have been using size_t. At
least the compiler will now point it out to them.
- Jonathan M Davis
_______________________________________________
phobos mailing list
<a class="moz-txt-link-abbreviated" href="mailto:phobos@puremagic.com">phobos@puremagic.com</a>
<a class="moz-txt-link-freetext" href="http://lists.puremagic.com/mailman/listinfo/phobos">http://lists.puremagic.com/mailman/listinfo/phobos</a>
</pre>
</blockquote>
<br>
</body>
</html>