Obviously, nothrow documents the behavior of a function and is checked when the code is available to the compiler.

At first glance, one could assume a nothrow function can save the compiler from the need to generate exception handling stuff for a function. But since nothrow doesn't mean the function won't throw, but merely that it won't throw an Exception, what optimizations does nothrow enable?

On Monday, 26 October 2020 at 18:47:41 UTC, Q. Schroll wrote:
> Obviously, nothrow documents the behavior of a function and is checked when the code is available to the compiler.
>
> At first glance, one could assume a nothrow function can save the compiler from the need to generate exception handling stuff for a function. But since nothrow doesn't mean the function won't throw, but merely that it won't throw an Exception, what optimizations does nothrow enable?

Isn't proper unwinding of the stack only required for Exceptions?

On Mon, Oct 26, 2020 at 06:52:40PM +0000, Tobias Pankrath via Digitalmars-d wrote:
> On Monday, 26 October 2020 at 18:47:41 UTC, Q. Schroll wrote:
> > Obviously, nothrow documents the behavior of a function and is checked when the code is available to the compiler.
> > 
> > At first glance, one could assume a nothrow function can save the compiler from the need to generate exception handling stuff for a function. But since nothrow doesn't mean the function won't throw, but merely that it won't throw an Exception, what optimizations does nothrow enable?
> 
> Isn't proper unwinding of the stack only required for Exceptions?

Yes.  The compiler is permitted to skip stack unwinding code when throwing Errors.  So yes, nothrow does win you some optimizations in some cases.

That's one of the reasons user code generally shouldn't catch Errors -- because some unwinding code may have been skipped and your state may be inconsistent.  Continuing normal execution after catching an Error is definitely a no-no.


T

-- 
Life is too short to run proprietary software. -- Bdale Garbee

On Monday, 26 October 2020 at 18:47:41 UTC, Q. Schroll wrote:
> Obviously, nothrow documents the behavior of a function and is checked when the code is available to the compiler.
>
> At first glance, one could assume a nothrow function can save the compiler from the need to generate exception handling stuff for a function. But since nothrow doesn't mean the function won't throw, but merely that it won't throw an Exception, what optimizations does nothrow enable?

Another use-case is when you have functions or methods that are designed to be run as the entry point of a separate thread or fiber task.  An uncaught exception can cause the thread (or whole program) to hang, so having these functions guaranteed `nothrow` can be valuable.

Of course, this is a bit of a workaround for the lack of decent exception handling for these cross-thread/fiber cases, but that's a bigger technical discussion...

On Monday, 26 October 2020 at 18:47:41 UTC, Q. Schroll wrote:
> Obviously, nothrow documents the behavior of a function and is checked when the code is available to the compiler.
>
> At first glance, one could assume a nothrow function can save the compiler from the need to generate exception handling stuff for a function. But since nothrow doesn't mean the function won't throw, but merely that it won't throw an Exception, what optimizations does nothrow enable?

It's also extremely useful for when D code is being called from other languages. Throwing an exception from a function registered with Python is not a thing one wants to do, for instance.

On Tue, Oct 27, 2020 at 06:10:45PM +0000, Atila Neves via Digitalmars-d wrote:
> On Monday, 26 October 2020 at 18:47:41 UTC, Q. Schroll wrote:
[...]
> > At first glance, one could assume a nothrow function can save the compiler from the need to generate exception handling stuff for a function. But since nothrow doesn't mean the function won't throw, but merely that it won't throw an Exception, what optimizations does nothrow enable?
> 
> It's also extremely useful for when D code is being called from other languages. Throwing an exception from a function registered with Python is not a thing one wants to do, for instance.

But how does it help in the case of throwing an Error from a function registered with Python?  Arguably, that's something you even *more* wouldn't want to do.


T

-- 
Why waste time reinventing the wheel, when you could be reinventing the engine? -- Damian Conway

On Monday, 26 October 2020 at 18:47:41 UTC, Q. Schroll wrote:
> Obviously, nothrow documents the behavior of a function and is checked when the code is available to the compiler.
>
> At first glance, one could assume a nothrow function can save the compiler from the need to generate exception handling stuff for a function. But since nothrow doesn't mean the function won't throw, but merely that it won't throw an Exception, what optimizations does nothrow enable?

If the compiler doesn't have to think about recovery (i.e. errors should result in the program's termination) then the control flow analysis and register allocation can be improved. It's hard to measure because of the implementation of the function, but you can see it in the assembly sometimes.

On Tuesday, 27 October 2020 at 18:21:23 UTC, H. S. Teoh wrote:
> On Tue, Oct 27, 2020 at 06:10:45PM +0000, Atila Neves via Digitalmars-d wrote:
>> On Monday, 26 October 2020 at 18:47:41 UTC, Q. Schroll wrote:
> [...]
>> > At first glance, one could assume a nothrow function can save the compiler from the need to generate exception handling stuff for a function. But since nothrow doesn't mean the function won't throw, but merely that it won't throw an Exception, what optimizations does nothrow enable?
>> 
>> It's also extremely useful for when D code is being called from other languages. Throwing an exception from a function registered with Python is not a thing one wants to do, for instance.
>
> But how does it help in the case of throwing an Error from a function registered with Python?  Arguably, that's something you even *more* wouldn't want to do.
>
>
> T

Unfortunately, it doesn't. But errors are supposed to mean a non-recoverable problem anyway. I know it's not always like that in practice and that you don't want to crash someone's Excel sheet, but... making them nothrow makes me write a catch block, which makes me also catch errors.

On 10/28/20 8:52 AM, Atila Neves wrote:
> On Tuesday, 27 October 2020 at 18:21:23 UTC, H. S. Teoh wrote:
>> On Tue, Oct 27, 2020 at 06:10:45PM +0000, Atila Neves via Digitalmars-d wrote:
>>> On Monday, 26 October 2020 at 18:47:41 UTC, Q. Schroll wrote:
>> [...]
>>> > At first glance, one could assume a nothrow function can > save the 
>>> compiler from the need to generate exception > handling stuff for a function. But since nothrow doesn't > mean the function won't throw, but merely that it won't > throw an Exception, what optimizations does nothrow enable?
>>>
>>> It's also extremely useful for when D code is being called from other languages. Throwing an exception from a function registered with Python is not a thing one wants to do, for instance.
>>
>> But how does it help in the case of throwing an Error from a function registered with Python?  Arguably, that's something you even *more* wouldn't want to do.
>>
>>
>> T
> 
> Unfortunately, it doesn't. But errors are supposed to mean a non-recoverable problem anyway. I know it's not always like that in practice and that you don't want to crash someone's Excel sheet, but... making them nothrow makes me write a catch block, which makes me also catch errors.

How does it make you write a catch block? If you only call nothrow functions, then your function is nothrow. If you assert in your nothrow function, it won't complain about catching.

How does it make you write a catch block that catches Errors? Catching Exception is sufficient to shut up the compiler.

-Steve

On Wednesday, 28 October 2020 at 14:46:40 UTC, Steven Schveighoffer wrote:
> On 10/28/20 8:52 AM, Atila Neves wrote:
>> On Tuesday, 27 October 2020 at 18:21:23 UTC, H. S. Teoh wrote:
>>> On Tue, Oct 27, 2020 at 06:10:45PM +0000, Atila Neves via Digitalmars-d wrote:
>>>> [...]
>>> [...]
>>>> [...]
>>>
>>> But how does it help in the case of throwing an Error from a function registered with Python?  Arguably, that's something you even *more* wouldn't want to do.
>>>
>>>
>>> T
>> 
>> Unfortunately, it doesn't. But errors are supposed to mean a non-recoverable problem anyway. I know it's not always like that in practice and that you don't want to crash someone's Excel sheet, but... making them nothrow makes me write a catch block, which makes me also catch errors.
>
> How does it make you write a catch block? If you only call nothrow functions, then your function is nothrow. If you assert in your nothrow function, it won't complain about catching.
>
> How does it make you write a catch block that catches Errors? Catching Exception is sufficient to shut up the compiler.

Because the code I call from the nothrow function isn't nothrow itself. It's true that it won't force me to catch errors, but I tend to in wrapper code nearly automatically.

I realise now I didn't explain it well before.