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