Discussion Thread: DIP 1034--Add a Bottom Type (reboot)--Community Review Round 1

[Johannes Loher]

Am 06.05.20 um 21:07 schrieb Dennis:
> I'm considering changing it so that local noreturn variables give an
> error on usage instead of initialization.

Thats exactly how it should be done. From my point of view, there is no
reason why declaring a variable of type noreturn should assert(0). Only
accessing it should do that, at least for local variables. For example
consider the following code:

auto fun(alias f)() {
    alias Type = ReturnType!f;
    Type ret;
    ret = f();
    /* do something with ret */
}

noreturn throwingFunction() {
    throw new Exception("foobar");
}

noreturn nonReturningFunction() {
    for(;;){}
}


void main() {
    try {
    	fun!(nonReturningFunction)(); // should throw Exception("foobar")
    }
    catch(Exception e) {
        // silently ignore it
    }
    fun!(nonReturningFunction)(); // should loop forever
}

I am not 100% sure about the implications for global variables, but if
global variables of type noreturn are initialized explicitly, it will be
a compile error because it will either be an infinite loop at compile
time or throw an exception at compile time (I guess there are also some
other situations, like failed asserts in betterC, but they also are
compile errors).

If the variable is not initialized explicitly, I don't see any issue
with it compiling. However, as soon as the variable is accessed at
runtime, it must assert(0).

H.S. Theo and me had a long discussion about this stuff in one of the
review threads for DIP1017 and if I remember correctly we basically
agreed that this should be the behavior. The main reasoning was that
this way we can avoid special cases in generic code and there is no
reason not to do it that way, it's just natural. It would be a weird
special case to disallow declaring variables of any type (you apply the
same reasoning to void in the DIP for making void a proper unit type and
I wholeheartedly agree!). However I don't remember if we considered
global variables.

Aside from that: I really love this DIP, I was looking forward to it
since I noticed you were working on it! It (and also the void DIP) would
make D's type system feel much more natural. Thanks for your work!