On Wed, 27 Mar 2013 18:46:09 +0100 "deadalnix" <deadal...@gmail.com> wrote:
> On Wednesday, 27 March 2013 at 17:23:01 UTC, Timon Gehr wrote: > > I strongly disagree. What would be an example of the problems > > you are apparently experiencing? > > > > T foo(alias fallback)() { > // Do some processing return the result. If an error occurs > use fallback mechanism. > } > > Reasonable thing to do as fallback is to try another method > workaround the error, throw, whatever. > > The problem is that the fallback type inference makes it painful > to work with, especially if fallback is a template itself. > > For instance, in SDC, you can parse ambiguous things as follow : > parseTypeOrExpression!((parsed) { > static if(is(typeof(parsed) : Expression)) { > // Do something > } else { > throw SomeException(); > } > })(tokenRange); > > This is bound to fail. When a function never return, it make no > sens to force a type on it and the magic subtype typeof(null) > should be used (as typeof(null) can cast to anything, it is valid > to call the function in any condition). A "does not return" return type would be nice for other things anyway. For example: void error(string s) // Convenience helper { throw new MyException("blah blah blah: "~s); } void serveFilesForever() { while(true) listenAndRespond(); } int doStuff() { if(blah) return 1; else if(blah2) { // Bullshit compile error: // "Not all paths return a value" error("poop"); // Must add dead code, keep compiler happy: //assert(0); } else { // Same bullshit serveFilesForever(); //assert(0); } } Compare to: no_return error() // Convenience helper { //if(foo) return; // Oops! But compiler catches error. throw new MyException("blah blah blah"); } no_return serveFilesForever() { // This might be harder for the compiler to check :( while(true) listenAndRespond(); } int doStuff() { if(blah) return 1; else if(blah2) error("poop"); // No bullshit, just works else serveFilesForever(); // Whee! }