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.

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

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

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.

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