static try catch construct would be helpful

[Robert Fraser]

Bill Baxter wrote:
> When plugging types together sometimes you find this one is missing a 
> member or that one defines it in a different way than you expect or 
> maybe a function with some signature isn't supported.
> 
> What you'd like to do is say "compile this block if you can -- otherwise 
> leave it out"  It's like try-catch, but compile-time.
> Except you don't really want a 'catch'.  It's more like an 'else'.  So I 
> propose a new form of static:
> 
>    static if {
>       // some code
>    } else static if {
>       // other code
>    } else {
>       // last resort code
>    }
> 
> The idea is: if "some code" compiles, then use that, otherwise try 
> "other code", and finally if none of the other code blocks compiles, use 
> the else block.
> 
> And of course it could be mix-n-matched with regular static if()'s.
> 
> 
> ------
> Here's a motivating example taken from real code where I was wrapping 
> one struct with another.  The Inner type may or may not support a 
> particular signature of the "doSomething" function.
> 
> struct Outer(Inner)
> {
>    void doSomething(int a, int b, int c, int d)
>    {
>       _inner.doSomething(a,b,c,d);
>       // do something else here
>    }
> 
>     ...
> 
>    Inner _inner;
> }
> 
> Currently, the best way I've found to conditionalize that is:
> 
>    static if(is(typeof(_inner.doSomething(1,1,1,1)))) {
>    void doSomething(int a, int b, int c, int d)
>    {
>       _inner.doSomething(a,b,c,d);
>       // do something else here
>    }
>    }
> 
> Maybe there's a better way to write that one.. I'm not sure.  But the 
> signature of the thing that may or may not exist can be arbitrarily 
> complex.  It becomes difficult to think of an is-expression that can 
> test for what you want.   You can probably break out the test into a 
> separate template and make it so you can do
>     static if(is(DoSomeCheck!(....))
> but writing that DoSomeCheck is annoying too and starts to clutter your 
> source with lots of one-off gobbledy gook templates.
> 
> I think "argument-less static if blocks" would handle such cases nicely.
> 
> 
> There's a slight issue in that it could be pretty hard to debug with 
> compiler errors being silently ignored, but that happens currently with 
> the expressions inside "static if(is(...))" already.
> 
> --bb

I like it, although I'm not sure how difficult that'd be to implement in 
the DMDFE's current model. votes++, under the stipulation that all code 
in question must be syntactically correct, even if it's not semantically 
correct. Personally, I like "static try { } else static try { } else { 
}", which I think conveys the meaning better than static if. Also, I 
think there should definitely be a strong caution on the specs page that 
other methods should be tried first, since, as you mentioned, it can 
spuriously compile the wrong thing if you accidentally have an error there.