bearophile <[email protected]> wrote:
I like very much the idea of constraint blocks. Much better than
expanding func header line, reuses an existing syntactic construct, and
far cleaner.
But I'd like that syntax to allow for an error message for each
constraint. So it becomes like contract programming, done at
compile-time on types and compile-time constants, and the "in" keyword
is enough:
in {
static assert(isDynamicArray!T, "err msg 1");
static assert(isIterable!T, "err msg 2");
...
} body {
...
}
The problem with such a solution is that the compiler needs to evaluate
the 'in' clause differently from all other code, as code further down in
the 'in' clause could use parameters in a way that would be illegal at
compile-time. Hence the new keyword or, for giggles, why not 'static in'?
--
Simen
