• 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:

Enamex <enamex+d outlook.com> writes:

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.

Steven Schveighoffer <schveiguy yahoo.com> writes:

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

ketmar <ketmar ketmar.no-ip.org> writes:

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...

Enamex <enamex+d outlook.com> writes:

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?

 -Steve

Nothing 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.

Steven Schveighoffer <schveiguy yahoo.com> writes:

On 8/2/16 11:34 AM, Enamex wrote:
 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?

 -Steve

 Nothing wrong exactly. I just wanted some descriptive terms to use in
 some places. Like "unreachable()" or "unimplemented()".

Well, mixins could help:

enum unreachable = "assert(0)";

...
// usage
mixin(unreachable);

Or comments:

assert(0); // unreachable

 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