dmd 1.046 and 2.031 releases

[Derek Parnell]

On Tue, 07 Jul 2009 18:10:24 -0400, Robert Jacques wrote:

> On Tue, 07 Jul 2009 18:05:26 -0400, Derek Parnell <derek at psych.ward> wrote:
> 
>> On Tue, 07 Jul 2009 14:05:33 -0400, Robert Jacques wrote:
>>
>>
>>> Well, how often does everyone else use bytes?
>>
>> Cryptography, in my case.
>>
> 
> Cool. If you don't mind, what's you're take new rules? (As different use  
> cases and points of view are very valuable)

By new rules you mean the ones implemented in D 2.031?

I'm not sure yet. I need to use them more in practice to see how they sort
themselves out. It seems that what they are trying to do is predict runtime
behaviour at compile time and make the appropriate (as defined by Walter)
steps to avoid runtime errors.

Anyhow, and be warned that I'm just thinking out loud here, we could have a
scheme where the coder explicitly tells the compiler that, in certain
specific sections of code, the coder would like to have runtime checking of
overflow situations added by the compiler. Something like ...

   byte a,b,c;

   try {
     a = b + c;
   }
   catch (OverflowException e) { ... }

and in this situation the compiler would not give a message, because I've
instructed the compiler to generate runtime checking.

The problem we would now have though is balancing the issuing-of-messages
with the ease-of-coding. It seems that the most common kind of assignment
is where the LHS type is the same as the RHS type(s), so we don't want to
make that any harder to code. But clearly, this is also the most common
source of potential overflows. Ok, let's assume that we don't want the D
compiler to be our nanny; that we are adults and understand stuff. This now
leads me to think that unless the coder says differently, the compiler
should be silent about potential overflows. 

The "try .. catch" example above is verbose, however it does scream
"run-time checking" to me so it is probably worth the effort. The only
remaining issue for me is how to catch accidental overflows in the special
cases where I, as a responsible coder, knowingly wish to avoid.

Here is where I propose having a signal to the compiler about which
specific variables I'm worried about, and if I code an assignment to one of
these that can potentially overflow, then the compiler must issue a
message. 

NOTE BENE: For the purposes of these examples, I use the word "guard" as
the signal for the compiler to guard against overflows. I don't care so
much about which specific signalling method could be adopted. This is still
conceptual stuff, okay?

   guard byte a; // I want this byte guarded.
   byte b,c;     // I don't care about these bytes.

   a = 3 + 29; // No message 'cos 32 fits into a byte.
   a = b + c;  // Message 'cos it could overflow.
   a = cast(byte)(b + c);  // No message 'cos cast overrides messages.
   a++; // Message - overflow is possible.
   a += 1; // Message - overflow is possible.
   a = a + 1 // Message - overflow is possible.
   a = cast(byte)a + 1;  // No message 'cos cast overrides messages.

And for a really smart compiler ...

   a = 0; 
   a++; // No message as it can determine that the run time value
        // at this point in time is okay.

   for (a = 'a'; a <= 'z'; a++) // Still no message.

Additionally, I'm pretty certain that I think ...

  auto x = y + z;

should ensure that 'x' is a type that will always be able to hold any value
from (y.min + z.min) to (y.max + z.max) inclusive. 

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell