digitalmars.D.learn - Never-returning functions
- Enamex (13/13) Aug 02 2016 I've tried to write an 'assert function' in D, one that doesn't
- Steven Schveighoffer (3/15) Aug 02 2016 What's wrong with assert(0) that you need to have a wrapper function for...
- ketmar (6/8) Aug 02 2016 while this is a legitimate question, the comipler's inability to
- Enamex (7/10) Aug 02 2016 Nothing wrong exactly. I just wanted some descriptive terms to
- Steven Schveighoffer (17/27) Aug 02 2016 Well, mixins could help:
I've tried to write an 'assert function' in D, one that doesn't trigger the 'function must return a value or assert' error. Basically something like: Never neverReturns() { assert(0); } or noreturn auto neverReturns() { assert(0); } and int tryMe(bool f) { if(f) return 42; else neverReturns(); } Then have the call on line 2 in `tryMe` be accepted by the compiler.
Aug 02 2016
On 8/2/16 11:09 AM, Enamex wrote:I've tried to write an 'assert function' in D, one that doesn't trigger the 'function must return a value or assert' error. Basically something like: Never neverReturns() { assert(0); } or noreturn auto neverReturns() { assert(0); } and int tryMe(bool f) { if(f) return 42; else neverReturns(); } Then have the call on line 2 in `tryMe` be accepted by the compiler.What's wrong with assert(0) that you need to have a wrapper function for it? -Steve
Aug 02 2016
On Tuesday, 2 August 2016 at 15:18:31 UTC, Steven Schveighoffer wrote:What's wrong with assert(0) that you need to have a wrapper function for it?while this is a legitimate question, the comipler's inability to infer "noreturn" still drives me mad. but if compiler will suddenly be able to infer that, it would lead to alot of "statement unreachable" warnings, and they are alot already...
Aug 02 2016
On Tuesday, 2 August 2016 at 15:18:31 UTC, Steven Schveighoffer wrote:What's wrong with assert(0) that you need to have a wrapper function for it? -SteveNothing wrong exactly. I just wanted some descriptive terms to use in some places. Like "unreachable()" or "unimplemented()". To be clear (and correct my original post now that I see it may have alluded to this), I want to say a function always 'throws', not necessarily asserts.
Aug 02 2016
On 8/2/16 11:34 AM, Enamex wrote:On Tuesday, 2 August 2016 at 15:18:31 UTC, Steven Schveighoffer wrote:Well, mixins could help: enum unreachable = "assert(0)"; ... // usage mixin(unreachable); Or comments: assert(0); // unreachableWhat's wrong with assert(0) that you need to have a wrapper function for it? -SteveNothing wrong exactly. I just wanted some descriptive terms to use in some places. Like "unreachable()" or "unimplemented()".To be clear (and correct my original post now that I see it may have alluded to this), I want to say a function always 'throws', not necessarily asserts.This kind of flow control I don't think the compiler will infer. One thing you *could* do, is to define your function to return the appropriate return type, but of course it never will: T alwaysThrows(T)() { throw new Exception("blammo!"); return T.init; } int tryMe(bool f) { if(f) return 42; else return alwaysThrows!int; // or typeof(return) } -Steve
Aug 02 2016