proposed @noreturn attribute

[via Digitalmars-d]

On Tuesday, 18 July 2017 at 22:03:27 UTC, Walter Bright wrote:
> On 7/17/2017 4:26 PM, H. S. Teoh via Digitalmars-d wrote:
>> But the point is that so much time and effort is being spent on
>> discussing and designing a feature that you have admitted 
>> yourself to be
>> "rarely used". As a disinterested bystander I find it somewhat 
>> amusing
>> (and sad) to see so much over-engineering of an overly-complex 
>> system
>> involving a new basic type in the language, which in turn 
>> entails all
>> sorts of corner cases in how it will interact with existing 
>> types and
>> constructs, not to mention the implementation complexities 
>> that will be
>> involved to pull it off -- all for what?  Just to be able to 
>> say
>> "function F doesn't return".  Seems like disproportionate 
>> effort for
>> only marginal returns (har har).
>
> The issue here (for me) is to have a type system that matches 
> type systems used in type theory. D already has strong 
> abilities to do type calculus. Instead of inventing our own 
> whackadoodle scheme, one hack at a time, why not match existing 
> type calculus? Then, attempts to do type calculus in D will 
> work as worked out by type theory.
>
> Or, we could go with the C++ approach which historically is to 
> add an ad-hoc solution for an existing problem, and then 
> another ad-hoc solution for the whacky effects that turned out 
> to have, rinse, repeat. (Look at all the different ways to do 
> type deduction, a horrifying consequence. Or function 
> overloading, which started with complex special cases, then 
> changed to partial ordering for special cases.)

> [...]

Agreed. Discovered vs invented as Philip Wadler classifies the 
two approaches in his talk: 
https://www.youtube.com/watch?v=IOiZatlZtGU, which I highly 
recommend watching.