Bottom Type--Type Theory

[Olivier FAURE]

On Thursday, 17 January 2019 at 23:05:58 UTC, H. S. Teoh wrote:
> It does lead to other corner cases like structs that contain 
> Bottom fields -- instantiating such a struct should abort at 
> runtime, and void initialization should be illegal -- so this 
> special case is infectious and may lead to increased compiler 
> complexity. OTOH, maybe this complexity can be nipped in the 
> bud by stipulating that any aggregate that contains Bottom 
> reduces to Bottom, i.e., any struct or class that contains a 
> Bottom field will be defined to be Bottom itself (since it 
> would be impossible to create an instance of such a struct or 
> class without also creating an instance of Bottom).

I think this solution would also create its own corner cases.

For instance, if you were to write:

     auto callEach(Functions...)(Functions functions) {
         ReturnTypesOf!Functions returnValues;

         static forearch(i, f; functions) {
             returnValues[i] = f();
         }

         return returnValues;
     }

     // Later...
     auto handleError = () => throw SomeException;
     callEach(&foo, &bar, &handleError);

The function would abort near the beginning with no error 
message, instead of throwing when handleError is called.

I think there are two solutions to this problem:
- Forbid any aggregate to include a Bottom type, which would 
severely limit Bottom's use as a first-class type.
- Rework the type system to gracefully handle types with no .init 
value.

In the second case, Bottom, Bottom[10] and struct Foobar { Bottom 
x; } would all be legal, distinct types. Their only common point 
would be that they would all have a "no .init" trait.