link: https://github.com/dlang/DIPs/pull/9
file: https://github.com/Superstar64/DIPs/blob/exception_extensions/DIPs/DIP1001.md

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

You don't have to use gc-allocated exceptions anyway.
Allowing to throw any type makes chaining impossible.

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

Adding another attribute to the language and having the compiler do magic behind the scenes?

No thanks.

On Sun, 10 Jul 2016 19:55:37 +0000, Superstar64 wrote:

> link: https://github.com/dlang/DIPs/pull/9 file: https://github.com/Superstar64/DIPs/blob/exception_extensions/DIPs/
DIP1001.md

So if my function calls any runtime functions -- it allocates memory, slices an array, etc -- I can't use C-style exception handling. Unless I manually do something like:

struct ThrowableWrapper {
  Throwable error;
}
int[] foo(int i) {
  try {
    return [i];
  } catch (Throwable t) {
    throw ThrowableWrapper(t);
  }
}

On Sunday, 10 July 2016 at 20:30:56 UTC, Stefan Koch wrote:
> 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
>
> You don't have to use gc-allocated exceptions anyway.
> Allowing to throw any type makes chaining impossible.

Can you please explain why it makes chaining impossible?

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.

On Sunday, 10 July 2016 at 21:43:08 UTC, Chris Wright wrote:
> On Sun, 10 Jul 2016 19:55:37 +0000, Superstar64 wrote:
>
>> link: https://github.com/dlang/DIPs/pull/9 file: https://github.com/Superstar64/DIPs/blob/exception_extensions/DIPs/
> DIP1001.md
>
> So if my function calls any runtime functions -- it allocates memory, slices an array, etc -- I can't use C-style exception handling. Unless I manually do something like:
>
> struct ThrowableWrapper {
>   Throwable error;
> }
> int[] foo(int i) {
>   try {
>     return [i];
>   } catch (Throwable t) {
>     throw ThrowableWrapper(t);
>   }
> }

You could use both c style and d stack unwinding:
---
struct CustomErrorCode
{
    enum __ErrorCode = true;

}

struct CustomUnwind
{

}

int foo(int[] arr, int index) @throws(Throwable,CustomErrorCode,CustomUnwind)
{
    auto val = arr[index]; // may throw RangeError with d's existing handling
    if (val == 0xdead)
    {
        throw CustomErrorCode(); // throws using new error code handling
    }
    else if (val == 0xbad)
    {
        throw CustomUnwind(); // throws using new by value unwinding
    }
}
---

Or possible wrap your function in a template that catch Unwind exceptions and throws Error Codes.

On Sunday, 10 July 2016 at 21:52:37 UTC, Lodovico Giaretta wrote:
> 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.

This proposal allows you to switch between error code handling and
stack unwinding by just switching one line of code.

> 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.

Wouldn't that still require allocation for the exception's message
and stack trace?

> 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.

Throw lists where added because they are required for this to
work with incremental compilation.

> 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.

Nothing wrong on my end.

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

https://forum.dlang.org/post/auplvezvpisiufwvddfo@forum.dlang.org

On Monday, 11 July 2016 at 12:36:59 UTC, Basile B. wrote:
> 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
>
> https://forum.dlang.org/post/auplvezvpisiufwvddfo@forum.dlang.org

@SuperStar64, please ignore the troll(s) and keep working on your proposal by incorporating the constructive critic you have received so far. As Dicebot already stated it's very important to provide good & convincing arguments in favor of your proposal because changing a language isn't a simple thing and (may) have wide implications.