I was thinking of adding some keywords like final, pure, and nothrow in to my library to improve various things where improvements could be made. As I was thinking about this, I wondered about my extern(C) function declarations and how keywords could improve those as well.

Since the C functions can't access anything from D code save for what is passed through as parameters, can it be called pure? And if so, does the compiler know how to distinguish C and D in this instance and make it inherently pure? Does purity do anything in terms of speed/safety here?

I noticed that in Deimos and Derelict that most(if not all) C function declarations are marked as nothrow. What are the speed/safety benefits of including this? And likewise as with the pure aspect, does the compiler know how to distinguish C and D and make it inherently nothrow?

C's name mangling doesn't allow function overloading, but as far as I know you can overload extern(C) functions in D. Does adding final help with speed improvements in the D side of things if added to an extern(C) function declaration?

Thanks much!

> Since the C functions can't access anything from D code save for what is passed through as parameters, can it be called pure?

Probably not since it might not be pure and eg. mutate global variables.

> Does purity do anything in terms of speed/safety here?
A pure function is expected to give the same result given the same parameters.
Similar calls to a pure function (same parameters) can be optimized out by the compiler.

> I noticed that in Deimos and Derelict that most(if not all) C function declarations are marked as nothrow. What are the speed/safety benefits of including this?

No speed or safety benefit, but it allows to call these C functions in functions marked nothrow themselves. As a rule of thumb you can put nothrow systematically when binding C code.

> And likewise as with the pure aspect, does the compiler know how to distinguish C and D and make it inherently nothrow?

No.

> C's name mangling doesn't allow function overloading, but as far as I know you can overload extern(C) functions in D. Does adding final help with speed improvements in the D side of things if added to an extern(C) function declaration?

No.

On 2013-12-28 22:47, Jeremy DeHaan wrote:

> Since the C functions can't access anything from D code save for what is
> passed through as parameters, can it be called pure? And if so, does the
> compiler know how to distinguish C and D in this instance and make it
> inherently pure? Does purity do anything in terms of speed/safety here?

It can access global variables.

-- 
/Jacob Carlborg

On Sat, Dec 28, 2013 at 09:57:06PM +0000, ponce wrote: [...]
> >I noticed that in Deimos and Derelict that most(if not all) C function declarations are marked as nothrow. What are the speed/safety benefits of including this?
> 
> No speed or safety benefit, but it allows to call these C functions in functions marked nothrow themselves. As a rule of thumb you can put nothrow systematically when binding C code.
[...]

Yes, since C code will not throw D exceptions (C doesn't know anything about D exceptions). Unless you pass in a function pointer to a D function that does throw an exception... but that case doesn't work for other reasons, so it generally shouldn't be done. So, barring that, all C code is automatically nothrow.


T

-- 
What do you call optometrist jokes? Vitreous humor.

On Sunday, 29 December 2013 at 14:50:52 UTC, H. S. Teoh wrote:
> Yes, since C code will not throw D exceptions (C doesn't know anything
> about D exceptions). Unless you pass in a function pointer to a D
> function that does throw an exception... but that case doesn't work for
> other reasons, so it generally shouldn't be done. So, barring that, all
> C code is automatically nothrow.

Some C libraries are designed to support long-jumping or throwing[1] out of some of their callbacks (when they are, it will be explicitly stated in the documentation). These callbacks need not necessarily be marked nothrow. Of course, the C function that calls the callback should have the same throwness as the callback - if one is marked as nothrow, both should be, and vice versa.

Interestingly, D programs that catch non-Exception's and try to return to a normal path of code execution will be extra prone to spectacular failure if they use C libraries with callbacks that don't support long-jumping out of them, which is most...

[1] Whether stack-unwinding will work is dependent on the exception mechanism and sometimes compilation flags etc.