dmd 1.046 and 2.031 releases

[Jarrett Billingsley]

On Tue, Jul 7, 2009 at 11:33 AM, Andrei
Alexandrescu<SeeWebsiteForEmail at erdani.org> wrote:
>
> Well 32-bit architectures may be a historical relic but I don't think 32-bit
> integers are. And I think it would be too disruptive a change to promote
> results of arithmetic operation between integers to long.
>
> ...
>
> This is a different beast. We simply couldn't devise a satisfactory scheme
> within the constraints we have. No simple solution we could think of has
> worked, nor have a number of sophisticated solutions. Ideas would be
> welcome, though I need to warn you that the devil is in the details so the
> ideas must be fully baked; too many good sounding high-level ideas fail when
> analyzed in detail.

Hm.  Just throwing this out there, as a possible solution for both problems.

Suppose you kept the current set of integer types, but made all of
them "open" (i.e. byte+byte=short, int+int=long etc.).  Furthermore,
you made it impossible to implicitly convert between the signed and
unsigned types of the same size (the int<>uint hole disappears).

But then you introduce two new native-size integer types.  Well, we
already have them - ptrdiff_t and size_t - but give them nicer names,
like word and uword.  Unlike the other integer types, these would be
implicitly convertible to one another.  They'd more or less take the
place of 'int' and 'uint' in most code, since most of the time, the
size of the integer isn't that important.