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

Meta jared771 at gmail.com
Wed May 6 17:03:56 UTC 2020


On Wednesday, 6 May 2020 at 16:39:30 UTC, Dennis wrote:
> On Wednesday, 6 May 2020 at 16:22:48 UTC, Meta wrote:
>> Why are these defined to cause a compile error?
>
> My reasoning is that the following are all equivalent:
>
>> noreturn x;
>> noreturn x = noreturn.init;
>> noreturn x = assert(0);
>> auto x = assert(0);
>> auto x = () {assert(0);} ();
>
> The bottom one gives a compile error today.
>
>> Error: `assert(0)` failed
>
> I don't intend to change that. (This comparison with errors 
> during CTFE is also mentioned in "Interaction with other 
> language features" by the way).

The problem is that these require special cases in generic code. 
If these common cases cause compile errors, then every template 
will either have to have a `if (!is(T == noreturn))`, or allow 
itself to fail (possibly deep inside a stack of instantiated 
templates).

std.algorithm.group, for example, returns a Group struct, defined 
as follows:

struct Group(alias pred, R)
if (isInputRange!R)
{
     import std.typecons : Rebindable, tuple, Tuple;

     private alias E = ElementType!R;
     static if ((is(E == class) || is(E == interface)) &&
                (is(E == const) || is(E == immutable)))
     {
         private alias MutableE = Rebindable!E;
     }
     else static if (is(E : Unqual!E))
     {
         private alias MutableE = Unqual!E;
     }
     else
     {
         private alias MutableE = E;
     }

     private R _input;
     private Tuple!(MutableE, uint) _current;
     ...
}

But if R is noreturn[], then this becomes:

struct Group(alias pred, R)
if (isInputRange!R)
{
     private noreturn[] _input;
     private Tuple!(noreturn, uint) _current;
}

And because Tuple is itself a struct, and Tuple!(noreturn, uint) 
has a field of type noreturn, the following code will fail to 
compile:

[].group()

With a confusing error message inside Tuple.

Maybe this is not a realistic scenario, but I think it should at 
least be considered that this will cause code that previously 
seemed fairly innocuous to now fail to compile, for a reason that 
may not be obvious.


More information about the Digitalmars-d mailing list