proposed @noreturn attribute

Guillaume Boucher via Digitalmars-d digitalmars-d at puremagic.com
Sun Jul 16 12:49:26 PDT 2017


On Sunday, 16 July 2017 at 13:03:40 UTC, Timon Gehr wrote:
>> I don't think that's true.  A Bottom type does not cover all 
>> use cases of @noreturn/@pragma(noreturn).
>> ...
>
> I think it does, but it is a significantly more invasive 
> language change.

The best you can hope for is that any code with pragma(noreturn) 
can be rewritten into functionally equivalent code that uses 
Bottom and gives the same hints to the optimizer.

pragma(noreturn) can be inferred implicitly which makes it more 
impactful in practice.

> I'd say a function with return type Bottom can override any 
> function in the base class.

That solves the "Penguin : Bird" step, but not "EvolvedPenguin : 
Penguin" (which can fly).

Andrei argues that my example don't comply with a puristic 
understanding of inheritance.  Maybe that's enough of a reason to 
not optimize such use cases, but it still shows that 
pragma(noreturn) is somehow stronger than Bottom.


> pragma(noreturn) is indeed the simpler solution, as it does not 
> interact with anything else. The fact that template constraints 
> in some cases need to be aware of the existence of Bottom in 
> order to work for Bottom is clearly a negative property of this 
> solution in the context of D.

Yes, basically this.


> You can return 'auto' instead of U. Then the return type will 
> be inferred either as U or Bottom.

Sure there are workarounds.  Also here:

auto deref(T)(ref T* x) { return deref(*x); }
ref T deref(T)(ref T x) if (!isPointer!T) { return x; }

But when every small function needs a rewrite, something seems 
off.


More information about the Digitalmars-d mailing list