proposed @noreturn attribute
Nick Sabalausky (Abscissa) via Digitalmars-d
digitalmars-d at puremagic.com
Sun Jul 9 11:46:54 PDT 2017
On 07/08/2017 08:17 AM, Andrei Alexandrescu wrote:
> On 7/8/17 6:15 AM, Walter Bright wrote:
>> Has anyone a better idea? Does anyone want to write a DIP for this?
>
> An attribute is fine. A more PL-minded possibility is to return a
> specific type:
>
> struct None
> {
> @disable this();
> @disable this(this);
> @disable @property None init();
> }
>
> None ThisFunctionExits();
>
> The compiler detects (without having anything hardwired about the
> particular type "None") that the type None is impossible to create and
> copy/move from a function, and therefore decrees the function will never
> return.
Pro:
- Having the indication "this doesn't return" syntactically be the
return type makes a lot of sense. I like that a lot. (Though I'd have no
objection to Walter's original suggestion either).
- It's one less built-in @attribute to scare people away with objections
of "too many attributes"! (And admittedly, idiomatic D can end up with
lots of attribtes all over the place.)
Con:
- Inferring that a type is meant to indicate "functions 'returning' this
do not return", strikes me as very round-about, hackish, unintuitive and
just unclean.
I really think this is one case where a dedicated compiler-understood
symbol is not only fully justified but also much cleaner.
That would be my #1 top preference: Your suggestion here, but just make
"NoReturn" (or whatever it'll be called) a special compiler-understood
"type", not something inferred from the detailed of a library-provided type.
In any case, I'm definitely onboard with the idea of having SOME
standard way to tell the compiler "this does not return". That would be
nice to have.
More information about the Digitalmars-d
mailing list