On Friday, 10 January 2020 at 16:01:26 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 10 January 2020 at 15:43:35 UTC, Jesse Phillips wrote:
>> C++ remove exception specification but kept `noexcept` and `throw()` both of which behave like the desired `throw` discussed here for D.
>
> No, "throw()" is not only deprecated, it is removed in C++20.

My searches come up empty handed, but I'm applying the incorrect semantics to throw(), that is equal to the noexcept semantics which is equal to D's nothrow. I don't see the same proposed semantics in c++.

On Friday, 10 January 2020 at 16:32:33 UTC, Jesse Phillips wrote:
> My searches come up empty handed, but I'm applying the incorrect semantics to throw(), that is equal to the noexcept semantics which is equal to D's nothrow. I don't see the same proposed semantics in c++.

That's right. C++ has the "noexcept" speficier which also can be expressed as "noexcept(true)" in generic programming, but the default is "noexcept(false)" (with a few special cases).

The C++ semantics is the opposite of nothrow by default.

On Friday, 10 January 2020 at 16:46:32 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 10 January 2020 at 16:32:33 UTC, Jesse Phillips wrote:
>> My searches come up empty handed, but I'm applying the incorrect semantics to throw(), that is equal to the noexcept semantics which is equal to D's nothrow. I don't see the same proposed semantics in c++.
>
> That's right. C++ has the "noexcept" speficier which also can be expressed as "noexcept(true)" in generic programming, but the default is "noexcept(false)" (with a few special cases).
>
> The C++ semantics is the opposite of nothrow by default.

My point is c++ is not removing what is being proposed for adding 'throw'

On Friday, 10 January 2020 at 22:00:08 UTC, Jesse Phillips wrote:
> My point is c++ is not removing what is being proposed for adding 'throw'

What do you mean? C++ has "throw" as the default. Noexcept is the outlier, so yes, they did remove it.

On Friday, 10 January 2020 at 22:27:35 UTC, Ola Fosheim Grostad wrote:
> On Friday, 10 January 2020 at 22:00:08 UTC, Jesse Phillips wrote:
>> My point is c++ is not removing what is being proposed for adding 'throw'
>
> What do you mean? C++ has "throw" as the default. Noexcept is the outlier, so yes, they did remove it.

Throw was always the default, just like D.

On Saturday, January 11, 2020 1:02:09 AM MST Jesse Phillips via Digitalmars- d wrote:
> On Friday, 10 January 2020 at 22:27:35 UTC, Ola Fosheim Grostad
>
> wrote:
> > On Friday, 10 January 2020 at 22:00:08 UTC, Jesse Phillips
> >
> > wrote:
> >> My point is c++ is not removing what is being proposed for adding 'throw'
> >
> > What do you mean? C++ has "throw" as the default. Noexcept is the outlier, so yes, they did remove it.
>
> Throw was always the default, just like D.

Yes. What C++ had was a runtime attempt at what Java does. You would optionally specify which exceptions could be thrown from a function (whereas in Java, it's mandatory to specify). So, if you had

int foo(std::string bar);

then the function could throw anything (even stuff like int, since C++ didn't restrict exception types at all), whereas if you had

int foo(std::string bar) throw(MyExceptionType);

then the function could only throw the type MyExceptionType. This is similar to Java, but whereas Java statically restricts what can be thrown, C++ did it at runtime. So, there were _zero_ compile-time checks that no other types were thrown, and if something else were thrown, it would basically kill your program. This was a terrible, terrible idea, which is why they started phasing it out with C++11.

The one aspect of it which was arguably a good idea was throw() - e.g.

int foo(std::string bar) throw();

which was their version of nothrow. It was still a runtime check, but there are cases where you absolutely can't have an exception be thrown (destructors being the primary use case), so while it's still bad that it's a runtime check, it's deemed better to kill the program in such a case than to continue. So, C++11 introduced noexcept to replace it. e.g.

int foo(std::string bar) noexcept;

noexcept does the same thing as throw(), but throw() is going away along
with throw(MyExceptionType). So, with throw(...) removed, C++ ends up with a
solution similar to what we currently have in D except that noexcept is a
runtime check, whereas nothrow is a compile-time check, and D lets
non-Exception Throwables be thrown anyway, which can get a bit weird.

If we were to add throw as a function attribute and make nothrow the default, that would be the opposite of what C++ has, just like it's the opposite of what we currently have in D.

- Jonathan M Davis

On Saturday, 11 January 2020 at 14:38:50 UTC, Jonathan M Davis wrote:
> noexcept does the same thing as throw(), but throw() is going away along

Not quite. In c++17 throw() was redefined to noexcept, but prior to this it should unwind the stack with unexpected as the exception. Noexcept may or may not unwind the stack and allow optimizations.

> with throw(MyExceptionType). So, with throw(...) removed, C++ ends up with a
> solution similar to what we currently have in D except that noexcept is a

Noexcept is now part of the function type and you can test expressions with the noexcept operator. I believe it is more to support generic programming and optimization than to prevent bad behaviour.

On Saturday, 11 January 2020 at 22:57:22 UTC, Ola Fosheim Grostad wrote:
> On Saturday, 11 January 2020 at 14:38:50 UTC, Jonathan M Davis wrote:
>> noexcept does the same thing as throw(), but throw() is going away along
>
> Not quite. In c++17 throw() was redefined to noexcept, but prior to this it should unwind the stack with unexpected as the exception.

The unexpected handler ( not a regular exception).

On Saturday, 4 January 2020 at 21:38:53 UTC, Walter Bright wrote:
> The first step is to add `throw` as a function attribute,
>
> https://github.com/dlang/DIPs/pull/167
>
> The next step will be to make nothrow the default. I have not prepared a DIP for that yet, but will.
>
> The short rationale is that exceptions being a "pay only if you use them" is a complete fraud. They're expensive to support, meaning performance programs use other ways of signalling errors and use nothrow.

Do you have a plan for standardizing an alternative recoverable-error-signalling method?  For example `Result` types?  Or something else?