bottom type as parameter or local variable, does that make sense?

H. S. Teoh hsteoh at quickfur.ath.cx
Fri Jan 14 17:41:09 UTC 2022


On Fri, Jan 14, 2022 at 04:32:22PM +0000, Paul Backus via Digitalmars-d wrote:
> On Friday, 14 January 2022 at 15:07:13 UTC, H. S. Teoh wrote:
[...]
> > IMO, that's a bug.  Implicit initialization of noreturn should
> > behave exactly the same way as invoking noreturn.init explicitly.
> > 
> > Somebody should file a bug, if one hasn't been filed already.
> 
> That's not what the bug is here. `noreturn` is the type of expressions
> whose evaluation does not halt; i.e., it is a type with no values.
> Therefore, declaring a variable of type `noreturn` is a no-op: all it
> does is add a symbol to the current scope. No initialization is
> performed, because there is nothing to initialize.

But in D, whenever a variable is declared, it gets initialized to its
default value unless specified otherwise. Since nothing is specified
here, it ought to perform its default initialization, and since there is
no value with which it can be initialized, it ought to raise a runtime
exception.


> On the other hand, this also means that any attempt to *evaluate* a
> `noreturn` *expression* (such as `noreturn.init`) can never succeed.
> So, a function call expression with a `noreturn` argument can never
> result in the function actually being called: it must either enter an
> infinite loop, throw an exception, terminate the program, etc.

In this case, the function never gets called, just as you said. But
neither does it enter an infinite loop, throw an exception, or terminate
the program.  So IMO there's definitely a bug here.


> Some `noreturn` expressions, like `throw new Exception` and `() {
> while(1) {} }()`, already had specific runtime behaviors defined by
> the language spec. Others, like `noreturn.init`, did not. For the
> latter kind of `noreturn` expression, the DIP specifies that their
> behavior at runtime is equivalent to `assert(0)`.

The `b` in `foo(b)` is an expression; the act of evaluating that
expression (in the course of calling foo) ought to terminate the program
with an assert(0). But it currently doesn't.  So it must be a bug.


T

-- 
Philosophy: how to make a career out of daydreaming.


More information about the Digitalmars-d mailing list