January 20, 2021
On 1/20/21 2:20 PM, Steven Schveighoffer wrote:
> I'll report it.

https://issues.dlang.org/show_bug.cgi?id=21565

-Steve
January 21, 2021
On 1/19/2021 5:04 PM, Andrei Alexandrescu wrote:
> On 1/19/21 4:50 PM, Q. Schroll wrote:
>> In C++, the noexcept specifier means you cannot throw anything.
>> In D,   the nothrow  specifier means you cannot throw Exceptions, but anything else.
> 
> Except that in C++, noexcept really means you can throw anything but you're not supposed to. Important distinction...

Time for throwing "soSueMe".
January 21, 2021
On 1/20/2021 2:51 AM, claptrap wrote:
> nothrow is still a terrible name for something that can still throw.

I tend to agree.

My thinking has evolved over the years, and I now think that Error should never be thrown, ever. If you have a non-recoverable error, you should just exit or call a user specified function. Not attempt to unwind the stack.

If someone wants to put a DIP out for that, I'd be favorably inclined.

January 21, 2021
On 1/20/2021 7:17 AM, Steven Schveighoffer wrote:
> That seems like a bug. Writing the x directly fails in @safe code.

It's a bug. Please file a bug report.
January 21, 2021
On Thursday, 21 January 2021 at 09:49:40 UTC, Walter Bright wrote:
> On 1/20/2021 2:51 AM, claptrap wrote:
>> nothrow is still a terrible name for something that can still throw.
>
> I tend to agree.
>
> My thinking has evolved over the years, and I now think that Error should never be thrown, ever. If you have a non-recoverable error, you should just exit or call a user specified function. Not attempt to unwind the stack.
>
> If someone wants to put a DIP out for that, I'd be favorably inclined.

We already have a compiler switch that is almost that.

  -checkaction=[D|C|halt|context]
                    behavior on assert/boundscheck/finalswitch failure

now if we had a version of that switch that could apply to all `throw x` where `is(typeof(x) : Error)) then that'd be great.

It's worth saying that we do depend on being able to catch Errors at Symmetry*, our situation is a little unusual though.

* "we are happy when a thrown Error is caught in some limited circumstances" not "our program is incorrect if any particular thrown Error is not caught"
January 21, 2021
On Wednesday, 20 January 2021 at 01:04:07 UTC, Andrei Alexandrescu wrote:
> On 1/19/21 4:50 PM, Q. Schroll wrote:
>> In C++, the noexcept specifier means you cannot throw anything.
>> In D,   the nothrow  specifier means you cannot throw Exceptions, but anything else.
>
> Except that in C++, noexcept really means you can throw anything but you're not supposed to. Important distinction...

Yup, one things that people miss is that noexcept actually makes things more expensive because the compiler has to add checks that you aren't throwing something. These are runtime checks that happen when unwinding an exception.
January 21, 2021
On Thursday, 21 January 2021 at 12:14:01 UTC, deadalnix wrote:
> Yup, one things that people miss is that noexcept actually makes things more expensive because the compiler has to add checks that you aren't throwing something. These are runtime checks that happen when unwinding an exception.

I would assume that only applies when calling functions in other compilation units? The throws within the noexcept function should just be replace with a call to std::terminate?

January 21, 2021
On Wednesday, 20 January 2021 at 15:10:09 UTC, Steven Schveighoffer wrote:
> I should say, it's undefined behavior if you ever use the immutable value and then mutate the value (just like if you cast it).

It would be worth mentioning these issues on the page that describes union.

I am hoping for an overhaul of union. I specifically don't want to see traced pointers in a union unless it is type-info compatible. This is currently blocking precise collection and destruction...

January 22, 2021
On 1/21/2021 3:12 AM, John Colvin wrote:
> It's worth saying that we do depend on being able to catch Errors at Symmetry*, our situation is a little unusual though.
> 
> * "we are happy when a thrown Error is caught in some limited circumstances" not "our program is incorrect if any particular thrown Error is not caught"

I recommend considering replacing it with Exception.
January 22, 2021
On Friday, 22 January 2021 at 09:28:47 UTC, Walter Bright wrote:
> On 1/21/2021 3:12 AM, John Colvin wrote:
>> It's worth saying that we do depend on being able to catch Errors at Symmetry*, our situation is a little unusual though.
>> 
>> * "we are happy when a thrown Error is caught in some limited circumstances" not "our program is incorrect if any particular thrown Error is not caught"
>
> I recommend considering replacing it with Exception.

The purpose is to catch unexpected Errors from any source, including accidental bounds violations, code deep in 3rd party dependencies etc. It doesn't matter if we miss some, but it's nice to catch them when we can.