• Jeremy DeHaan (20/20) Dec 28 2013 I was thinking of adding some keywords like final, pure, and
• ponce (11/23) Dec 28 2013 A pure function is expected to give the same result given the
• H. S. Teoh (11/18) Dec 28 2013 [...]
• Jakob Ovrum (14/23) Dec 29 2013 Some C libraries are designed to support long-jumping or
• Jacob Carlborg (4/8) Dec 29 2013 It can access global variables.

"Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:

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!

"ponce" <contact gam3sfrommars.fr> writes:

 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.

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

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.

"Jakob Ovrum" <jakobovrum gmail.com> writes:

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.

Jacob Carlborg <doob me.com> writes:

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