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