proposed @noreturn attribute

[Nicholas Wilson via Digitalmars-d]

On Monday, 10 July 2017 at 03:25:26 UTC, Nick Sabalausky 
(Abscissa) wrote:
> On 07/09/2017 05:14 PM, H. S. Teoh via Digitalmars-d wrote:
>> On Sun, Jul 09, 2017 at 02:01:08PM -0400, Andrei Alexandrescu 
>> via Digitalmars-d wrote:
>>> On 07/09/2017 12:19 PM, Steven Schveighoffer wrote:
>>>> It's no more of a hack than leaving assert(0) in release 
>>>> code.
>>>
>>> I wouldn't argue that. I do argue it's a hack compared to the
>>> principled solution of a bottom type. -- Andrei
>> 
>> I like out{ assert(0); } for pretty much the same reasons as 
>> Steven
>> lists. The biggest pro is that **the language already supports 
>> it*.
>> Contract syntax already is meant to signal intent, and 
>> assert(0) signals
>> "never gets here". You can't find a better solution than this. 
>> All the
>> other alternatives require adding even more baggage to an 
>> already
>> heavy language, or compiler voodoo to recognize a particular 
>> pattern of
>> defining a type.  I'd say out{assert(0);} is the principled 
>> solution --
>> expressing something the current language can already express, 
>> and it's
>> the other alternatives that are "exotic".
>> 
>
> Prioritizing "path of least resistense" over "this is cleaner 
> and more principled" is the hallmark of C++-style langauge 
> design. Please, please, please, let's stay away from that path.

While I agree with your sentiment in principle (heh), we need to 
keep in mind it purpose.
So far I count four requirements of a solution:
     documentation
     optimisation
     ability to statically reflect upon
     ability to implement

Of the approached listed only out{assert(0);} fails the static 
reflection check.
Which leaves
1)@noreturn
2)@disable(return)
3)none

1 & 2 are almost functionally identical in their implementation 
with 2 requiring some semantic hacks to the compiler and 
precludes the AliasSeq approach below, so I consider 1 to be 
superior to 2.

this leaves 1 & 3.

w.r.t documentation for 1 this is a solved problem, it becomes 
part of the type signature and will be picked up in the 
documentation building tools. 3 it becomes part of the return 
type and can also be solved by documenting the type.

w.r.t optimisation assuming both 1 & 3  impact DMD equally then 
there is no difference except that:

Implementation: 3 would require GDC and LDC to make changes _when 
they already have a solution_. It would also be _considerably 
more work_ than 1, and would be _backwards incompatible_ with 
older compilers. In fact 1 could be implemented _Immediately_ for 
GDC and LDC by having

enum __noreturn;
version (DigitalMars) alias noreturn = __noreturn;
else version(GNU) {
     import gcc.attributes : attribute;
     alias noreturn = AliasSeq!(__noreturn,attribute("noreturn"));
}
else version (LDC)
{
     import ldc.attributes : llvmAttr;
     alias noreturn = AliasSeq!(__noreturn,llvmAttr("noreturn"));
}

and reflect upon the presence of __noreturn;

I am strongly against the need to complicate the compiler when an 
equal (IMHO better) solution _already exists_, for extremely 
marginal gain: anyone seriously concerned about the small 
optimisation benefit will already be using GDC or LDC, the 
applicability of noreturn is minuscule, AFAICT C's _exit and an 
unconditional throw (Exception or Error) are the only functions 
for which it applies.