DIP 1017--Add Bottom Type--Final Review

[aliak]

On Wednesday, 16 January 2019 at 04:33:08 UTC, Nicholas Wilson 
wrote:
> On Wednesday, 16 January 2019 at 04:24:34 UTC, aliak wrote:
>> On Wednesday, 16 January 2019 at 01:14:58 UTC, Nicholas Wilson 
>> wrote:
>>> Those can all be done by an attribute. So it comes down to a 
>>> cost benefit analysis: the benefits they provide are the 
>>> same, except the implementation of bottom is going to be much 
>>> more costly.
>>
>> Is it "much" more costly?
>
> Bottom, must be implemented in the compiler. Attributes exist 
> _now_.
>
> version (LDC)
>     enum noreturn = ldc.attributes.llvmAttr("noreturn"));
> else version (GDC)
>     enum noreturn = gcc.attribute.attribute("noreturn"); // ?
> else version (DigitalMars)
>     enum noreturn;
>
> This exhibits the documentation benefits on all compilers, and 
> performance gains on the compilers that matter.
>
>> What about the benefit of not being able to write code like:
>>
>> @noreturn int f() { ... } // wat?
>
> Yes that is possible. Does it make sense to write? Of course 
> not. We shouldn't be taking into considerations of people 
> writing code like that when designing the language. `@noreturn 
> void` is what people use in C/C++ I don't see why that wouldn't 
> follow in D.

You'd have to take that in to consideration because you'd have to 
implement the logic to handle it though no? What would that logic 
be? Compiler error maybe ... 🤔 but then that's special casing in 
the compiler? (yuk). And I guess I just disagree with not taking 
how people would write code in to consideration.

A proper type gives you everything the attribute does, and has 
the advantage of not allowing for weird code, and makes the type 
system more solid, and provides future top-type possibilities. It 
sounds like the only argument for an attribute is "it's a bit 
quicker to implement" ... in which case I'd not vote for it.