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