DIP1001: Exception Handling Extensions

[Lodovico Giaretta via Digitalmars-d-announce]

On Sunday, 10 July 2016 at 19:55:37 UTC, Superstar64 wrote:
> link: https://github.com/dlang/DIPs/pull/9
> file: 
> https://github.com/Superstar64/DIPs/blob/exception_extensions/DIPs/DIP1001.md

I'm not convinced by this proposal. Here are some early thoughts:

1) Wouldn't a library solution based on functional-style tagged 
results achieve the same without changing the language and making 
things less clear (see my other points)? Something on the lines 
of variant?
2) Wouldn't this make code quite obscure? I mean, now if you see 
a throw or a catch you know what's going on. With this proposal, 
when you see a throw or a catch, you have to go look at the 
declaration of the thrown or catched type to get what's going on.
3) From your proposal, it seems that current exception handling 
needs the GC, which is not true; you can already do exception 
handling in @nogc code, without any extra quirk.
4) C++ deprecated throw lists; while this does not automatically 
mean that they are bad, we shall learn from others' errors, and 
be very careful.

But all of this is just my opinion based on a fast read of the 
proposal.

P.S.: something went wrong (probably with copy-pasting) here:
> A function which calls a sub function with a @throws(TypeList) 
> attribute must have
> alluncaught possible exceptions must be a part of the 
> @throws(TypeList) attribute of the
> caller function.