DMD 1.027 and 2.011 releases

[Georg Wrede]

    Caveat lector!
    Er, upon proofreading it dawned upon me:

        This post does NOT interest Walter or anybody
        else who is concerned with compiler issues,
        the laguage itself, or optimizing. (What, is that
        like everybody in this newsgroup??)

        BUT, it still is very relevant to the advancement
        of D.

        IDE developers, framework architects, and library
        programmers may want to read this.


Christopher Wright wrote:
> Georg Wrede wrote:
>> IMHO, it would behoove the compiler to keep track of 
>> possible/potential exceptions a function can throw. (Just as well as 
>> (again, IMHO) it would behoove the compiler to keep track of functions 
>> that /potentially/ have side effects.)
> 
> There's a few problems with what you're asking for:
> - extern(D)
> - .di files
> - delegates
> - dynamic loading

We probably should reverse the bookkeeping to what the function does 
/not/ throw. With that, the above things would all be classified as 
unknown, which translates to "no exception is guaranteed to not get 
thrown". (For recursive implications, see below.)

> There's also the matter of executable bloat.

All of this is compile-time-only stuff. Once compiled, the code should 
"look like" code that's never heard of the issue. But it still does the 
Right Thing.



To be more precise, we're not [here] interested in what a function 
throws, only in what it is guaranteed /not/ to throw. For example, an 
in-place string transformation would be guaranteed to not throw an 
out-of-memory exception. (Unless the programmer is an idiot, but that 
doesn't count here.)

By the same token, anytime I write a function in my code, the result of 
what other functions it calls and which they call in their turn, can be 
drawn as a tree structure. If we had machine readable documentation on 
each of the leaves, telling us /what it will not throw/, we might go on 
to the function that uses the leaf, see if it creates new kinds of 
exceptions and whether it may throw the new ones or any existing 
exceptions, and then compute the Set Intersection of the exceptions any 
of them /can not throw/. This gives us a guaranteed set of exceptions 
that /will not be thrown/ as a result of calling this (er...) 
Intermediate Node in the tree. By recursively applying this reasoning we 
ultimately end up with a hard document about my Brand New function, and 
what it doesn't throw.

(( And as you pointed out earlier, anytime any of the leaves or the 
nodes uses any of: extern(D), .di files, delegates, dynamic loading; the 
entire tree gets tainted. That might actually be a shortcut from 
traversing the tree since we don't need any more information: NO 
EXCEPTION is guaranteed not to be thrown. ))

While we're at it, this precisely same kind of analysis could be made 
about side effects. And even using precisely the same mechanics.

All we need is data on the primary functions. Everything else is 
automatically computable from that. Including the library functions. (As 
in Phobos, etc.)


The end result is, by the time we've written our own function, it is 
KNOWABLE what exceptions OUR function doesn't throw. And it is knowable 
whether our function DOES NOT create ANY side effects.

The value of these two hardly need advertising. Functional programming, 
real-time stuff, robust code, secure code, the list goes on and on.