On Tue, 07 Jul 2009 01:48:41 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Robert Jacques wrote:
On Mon, 06 Jul 2009 01:05:10 -0400, Walter Bright
<newshou...@digitalmars.com> wrote:
Something for everyone here.
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.046.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.031.zip
Thanks for another great release.
Also, I'm not sure if this is a bug or a feature with regard to the
new integer rules:
byte x,y,z;
z = x+y; // Error: cannot implicitly convert expression
(cast(int)x + cast(int)y) of type int to byte
which makes sense, in that a byte can overflow, but also doesn't make
sense, since integer behaviour is different.
Walter has implemented an ingenious scheme for disallowing narrowing
conversions while at the same time minimizing the number of casts
required. He hasn't explained it, so I'll sketch an explanation here.
The basic approach is "value range propagation": each expression is
associated with a minimum possible value and a maximum possible value.
As complex expressions are assembled out of simpler expressions, the
ranges are computed and propagated.
For example, this code compiles:
int x = whatever();
bool y = x & 1;
The compiler figures that the range of x is int.min to int.max, the
range of 1 is 1 to 1, and (here's the interesting part), the range of x
& 1 is 0 to 1. So it lets the code go through. However, it won't allow
this:
int x = whatever();
bool y = x & 2;
because x & 2 has range between 0 and 2, which won't fit in a bool.
The approach generalizes to arbitrary complex expressions. Now here's
the trick though: the value range propagation is local, i.e. all ranges
are forgotten beyond one expression. So as soon as you move on to the
next statement, the ranges have been forgotten.
Why? Simply put, increased implementation difficulties and increased
compiler memory footprint for diminishing returns. Both Walter and I
noticed that expression-level value range propagation gets rid of all
dangerous cases and the vast majority of required casts. Indeed, his
test suite, Phobos, and my own codebase required surprisingly few
changes with the new scheme. Moreover, we both discovered bugs due to
the new feature, so we're happy with the status quo.
Now consider your code:
byte x,y,z;
z = x+y;
The first line initializes all values to zero. In an intra-procedural
value range propagation, these zeros would be propagated to the next
statement, which would range-check. However, in the current approach,
the ranges of x, y, and z are forgotten at the first semicolon. Then,
x+y has range -byte.min-byte.min up to byte.max+byte.max as far as the
type checker knows. That would fit in a short (and by the way I just
found a bug with that occasion) but not in a byte.
That's really cool. But I don't think that's actually happening (Or are
these the bugs you're talking about?):
byte x,y;
short z;
z = x+y; // Error: cannot implicitly convert expression (cast(int)x +
cast(int)y) of type int to short
// Repeat for ubyte, bool, char, wchar and *, -, /
And by that logic shouldn't the following happen?
int x,y;
int z;
z = x+y; // Error: cannot implicitly convert expression (cast(long)x
+ cast(long)y) of type long to int
i.e. why the massive inconsistency between byte/short and int/long? (This
is particularly a pain for generic i.e. templated code)
BTW: this means byte and short are not closed under arithmetic operations,
which drastically limit their usefulness.
