Bottom type DIP 1017 and final rejection reasons?

Dennis dkorpel at gmail.com
Mon Mar 30 20:16:47 UTC 2020


On Monday, 30 March 2020 at 19:33:26 UTC, aliak wrote:
> Why does typeof(null) become noreturn*?

Because currently typeof(null) is a special case in the compiler 
that becomes redundant when you have a bottom type, since a 
pointer to a bottom type describes the behavior perfectly: it's a 
pointer that results in a program crash (a bottom value) when you 
dereference it.

> And is the only use case for noreturn[] being able to map on a 
> "void" array? Or are there other use cases?

map is just an example, the goal is to make any template taking a 
generic T[] to work on the empty array [].

> What's the use-case for being able to declare a variable of 
> type noreturn?

It is a degenerate case for generic code.
What's the use case for x + 0 or x >>> 0?
You wouldn't write that explicitly, but it might come up:
```
auto getBit(int i)(int n) {return (n >>> i) & 1;}
unittest {
     assert(getBit!0(0b0010) == 0); // does 0b0010 >>> 0
     assert(getBit!1(0b0010) == 1);
}
```

For noreturn, you might have a generic function like:

```
void foo(T)(T[] x) {
     if (x.length > 0) {
         T firstElem = x[0];
         // do stuff with firstElem
     }
}
```

If you call foo([]), then T = noreturn and you will declare 
`firstElem` with that type. That's okay though, since x.length 
will never be larger than 0 in that case, that branch will not be 
taken.

For more detailed rationale, please read the DIP and leave a 
review comment if something is unclear there.




More information about the Digitalmars-d mailing list