Understanding Safety of Function Pointers vs. Addresses of Functions

jmh530 via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Tue Jul 7 13:46:27 PDT 2015


On Tuesday, 7 July 2015 at 20:23:08 UTC, H. S. Teoh wrote:
>
> The reason for this is that function pointers have attributes 
> associated with them, as part of the type system. The address 
> of a @safe function is a @safe function pointer, meaning that 
> it's legal to call the function through this pointer in @safe 
> code. The address of a @system function is a @system function 
> pointer, which *cannot* be used to call the function from @safe 
> code.
>
> However, while it is not allowed to assign a @system function 
> pointer to a @safe function pointer (since that could be used 
> to bypass the @safe restriction on calling @system functions), 
> it is OK to assign a @safe function pointer to a @system 
> function pointer (this is called covariance). This is allowed 
> because a @system function pointer can only be dereferenced in 
> @system code, and @system code can freely call any function 
> with no restrictions. Where this might become a problem, 
> though, is when you inadvertently assign a @safe function 
> pointer to a @system function pointer, and then attempt to call 
> it from @safe code -- the compiler will reject that. This is 
> what happened with your sample code:
>

This, and the rest, does such a good job explaining why I have 
been so confused.
>
> Either that, or use `auto` to let the compiler figure out the 
> correct function pointer attributes for you:
>
> 	auto fp = &cbrt;
> 	pragma(msg, typeof(fp).stringof);
>

I've tried using auto, but I get errors when I use auto with a 
function that has been overloaded. For instance,
creal function(creal) pure nothrow @nogc @safe fp = &conj;
compiles, but
auto fp = &conj;
does not.


More information about the Digitalmars-d-learn mailing list