Currently I am using D pretty havily and I got across something to do with assertions and modules.

I use assertions quite havily due to the design and because I like design by contract. However I thing there could be one extension to it making assertions even more powerful. When an assertion fails, normally an AssertionError is thrown into the application, however, in for example a Date class, you might want to throw a different exception when such behaviour occurs, for example an ImpossibleDateException.

Syntatically it could very well look like

invariant throw ImpossibleDateException {
assert(day > 0 && day < 31);
..
}

The same goes for the in and out conditional checks with functions.

As for modules, which are a good thing, I have one struggle, it would be very handy if it was possible to specify a module within different files (without importing submodules or something in that manner). This makes it possible to write out module implementations across different files, which for large code segments, is very welcome. Another design might be to use path-extraction, what Java does, for modules, but I don't know if this is feasible. Something like partial modules may also be a solution to this, where a "boss" module dictates which files may partially implement a module.

Sjoerd van Leent wrote:

> Currently I am using D pretty havily and I got across something to do with
> assertions and modules.
> 
> I use assertions quite havily due to the design and because I like design by
> contract. However I thing there could be one extension to it making assertions
> even more powerful. When an assertion fails, normally an AssertionError is
> thrown into the application, however, in for example a Date class, you might
> want to throw a different exception when such behaviour occurs, for example an
> ImpossibleDateException.
> 
> Syntatically it could very well look like
> 
> invariant throw ImpossibleDateException {
> assert(day > 0 && day < 31);
> ..
> }
> 
> The same goes for the in and out conditional checks with functions.
> 
> As for modules, which are a good thing, I have one struggle, it would be very
> handy if it was possible to specify a module within different files (without
> importing submodules or something in that manner). This makes it possible to
> write out module implementations across different files, which for large code
> segments, is very welcome. Another design might be to use path-extraction, what
> Java does, for modules, but I don't know if this is feasible. Something like
> partial modules may also be a solution to this, where a "boss" module dictates
> which files may partially implement a module.
> 
> 

If you wanted to throw a different exception, you could just simply do:

invariant
{
  if(day < 0 || day > 31)
    throw new ImpossibleDateException(...);
}

If you wanted to do multiple assert statements, just combine them with logical operators.

I see no reason to add a few hundred lines of code to the frond-end just to handle throwing an exception other than AssertException when an assert() statement is reached.

-Deja