DIP 1029---Add throw as Function Attribute---Community Review Round 1

Ola Fosheim Grøstad ola.fosheim.grostad at gmail.com
Wed Jan 15 19:25:23 UTC 2020


On Wednesday, 15 January 2020 at 18:20:00 UTC, H. S. Teoh wrote:
> As I already pointed out in another thread, I suspect that 
> Walter's beef against exceptions is not really the exceptions 
> themselves, but their *current implementation* in the form of 
> mandatory stack frames and their associated setup, and stack 
> unwinding which is unwieldy to implement and expensive at 
> runtime to execute.

If that was the case then he would have suggested to fix the 
implementation, not the default...

You certainly can fix exception performance in the implementation 
with inter-procedural analysis.

> Elsewhere in said other thread we've already come up with a 
> potential alternative implementation that still allows you to 
> throw errors -- just in a more lightweight form that doesn't 
> require expensive stack frame setup and unwieldy stack 
> unwinding code.  At the user code level, it could even retain 
> exactly the same syntax, and work pretty much the same as 
> before, just the actual implementation will follow a different 
> scheme.

D needs to use the same unwind code as C++ if it is going to 
integrate well with C++.

If C++ interop is the goal then D has to focus on aligning its 
semantics with C++... obviously.



More information about the Digitalmars-d mailing list