DIP 1017--Add Bottom Type--Final Review

[Neia Neutuladh]

On Tue, 15 Jan 2019 18:21:25 +0000, Johannes Loher wrote:
>> Any attempt to use the value of a Tbottom expression is an error.
> 
> What does "use the value of a `Tbottom` expression" mean precisely?

assert(0)++, for instance, is not allowed.

It might not be allowed to write:

    void doNothing(T)(T value) {}
    doNothing(assert(0));

Depends on whether passing something to a function is considered "using" 
its value.

Combined with convertibility-style template constraints, this is going to 
explode in your face:

    void increment(T : long)(ref T value)
    {
        value++;
    }
    increment(assert(0));

While this example is contrived, it's inevitable that some people will run 
into it on occasion in more complex code, resulting in a lot of work to 
make every template bottom-safe.

> 14.
> The DIP proposes to add a type which is located at the bottom of the
> type hierarchy, but there is no mention at all of the dual concept—a top
> type, i.e. a type which every type implicitly converts to. From a type
> theory point of view, this asymmetry seems really weird. I'd like the
> DIP to go into if this is being considered and if not, why. It should
> probably be done in a "Future work" section or something similar.

As a library type, Variant, but that's not exactly within the type system.

> 16.
> Maybe not really relevant for the Final Review, but I find the DIP to be
> very difficult to understand at several places. This not due to the fact
> that the topic is actually very complicated,
> but rather because of style of the used language. In particular,
> it seems that the DIP author avoided using complete sentences in a lot
> of places where using a well formulated sentence could have made the
> intended meaning very clear. The "Expressions" section is a particularly
> bad example (at least to me, it was only possible to understand it with
> a lot of guess work).

Agreed. DIPs should use simple language and aim to use examples whenever 
possible. Brevity and sounding technical should be explicit non-goals.