proposed @noreturn attribute

Stefan Koch via Digitalmars-d digitalmars-d at puremagic.com
Mon Jul 17 15:23:18 PDT 2017


On Monday, 17 July 2017 at 18:54:37 UTC, H. S. Teoh wrote:
> On Mon, Jul 17, 2017 at 02:10:27PM -0400, Andrei Alexandrescu 
> via Digitalmars-d wrote:
>> On 7/17/17 11:39 AM, Olivier FAURE wrote:
>> > I'd really prefer if you avoided the whole 
>> > `typeof(assert(0))`
>> > thing.
>> > 
>> > First off, it's way too verbose for a simple concept.
>> 
>> Noted, thanks. I won't debate this much but for now I 
>> disagree. The "no return" type has several particular 
>> properties that set it aside (e.g. it's impossible to 
>> implement as a library, does things no other types do, etc).  
>> It's also used rarely. Therefore it stands to reason to 
>> consider an attention-seeking notation for it.
> [...]
>
> IMO, the observations "used rarely" and "attention-seeking 
> notation" are better satisfied by an attribute named @noreturn 
> than some strange, convoluted, arcane invocation like 
> `typeof(assert(0))`.  Because:
>
> (1) "used rarely" means it should be as non-intrusive as 
> possible as far as the language is concerned -- we should not 
> spend a lot of language real estate on something that's rarely 
> used, nor should it be something complicated to implement, 
> and/or introduces tricky corner cases that we're likely to get 
> wrong on first attempt. A @noreturn attribute is non-intrusive 
> -- doesn't interact with anything else in the language, easy to 
> implement -- has no tricky corner cases.
>
> (2) "attention-seeking": an arcane invocation like 
> `typeof(assert(0))` is harder to parse and therefore more 
> likely to invite people to just gloss over it as 
> "incomprehensible gibberish that I'll just ignore unless I have 
> to look further", than catch people's attention.  Whereas an 
> annotation like `@noreturn` is immediately obvious by its very 
> presence, with a name that instantly tells you what it does 
> while it still holds your attention.
>
> I see `typeof(assert(0))` as the same kind of over-engineering 
> of
> something trivially solved and relatively unimportant ("rarely 
> used")
> that has unfortunately plagued C++ design and led C++ to become 
> the mess
> it is today.  It's sad to see D start down the same path...
>
>
> T

+1000!
You've said it all!


More information about the Digitalmars-d mailing list