A potential solution to callable parameter attributes

[Herringway]

D has long had a problem where callable parameters and variables must have compatible attributes with the function being called. The "solutions" we have to this problem all have serious drawbacks:

1. Putting the same attributes on the callable parameter that the function has.
   • The "attribute soup" becomes especially overblown. You need overloads for every set of attributes you wish to support.
2. Template parameters.
   • Flexible, but can be very challenging to verify that the type of the callable actually matches what's expected; can result in a lot of extra instantiations that inflate compile times and binary sizes

On top of that, these solutions only cover the parameters. What about, for example, function pointers in global variables? Struct/class fields?

There have been a few proposals over the years (though the only DIP I'm aware of is DIP1032) and all have been quite complex and/or ugly. But what if there's been a much simpler solution right under our noses this entire time?

Have attribute checks ignore calling function pointers. Call a @system delegate in a @safe function? a function pointer doing I/O in pure functions? Yes! Let's allow it!

Instead, we do the attribute checks at assignment time. When the pointer is assigned to a variable or function parameter, the checks are done. For example:

void foo(void delegate() fun) pure {
  fun(); // fun's attributes don't matter
}
void bar() pure {
  foo({ myImpureFunction(); }); // error here - you can't call impure functions in bar(), it's pure
}
void baz() {
  foo({ myImpureFunction(); }); // but this is ok - baz() isn't pure
}

void delegate() fun;
void foo() @safe {
  fun(); // as above, fun's attributes don't matter
}
void bar() @safe {
  fun = { myUnsafeFunction(); }; // error here - you can't call @system functions in bar(), it's @safe
}
void baz() @system {
  foo = { myUnsafeFunction(); }; // but this is ok - baz() is @system
}

Although these function pointers aren't being called in bar/baz, by treating them as if they are, we still get the benefits of the attribute checks. This can even extend to CTFE, now that we have @system variables.

Function pointers that have attributes still have their attribute checks performed at assignment as they currently do. void delegate() @safe foo = &bar.systemFunction; will still fail to compile.

What do you think? Does this proposal have any major holes? Rip and tear!

[Herringway]

Instead of assignment, this should probably use function pointer creation (&fun, lambdas, etc) instead of assignment as the point to check attributes.

[dkorpel]

I might be misunderstanding this, but doesn't this completely change the meaning of attributes and/or break code?

void throwing() { throw new Exception(""); }

void function() x = &throwing; // disallowed now?

void main() @nogc nothrow
{
    x(); // allowed now?
}

struct S
{
    void function() callback;

    void setCallback(void function() callback) @safe pure nothrow @nogc { this.callback = callback; }
}

void f() {}

void main() @safe
{
    S s;
    s.setCallback(&f); // disallowed now?
}

That being said, I'm all for overhauling function attributes. Personally I would rip them all out of the type system entirely, but that may be an even more radical change.

[dkorpel]

That hinges on the unchecked assumption that the function attributes in the scope of the pointer's creation and the scope where the pointer gets called are the same. I don't understand how the compiler would even communicate violations, for example:

import std;
import core.sys.posix.dlfcn;

extern(C) size_t function(const(char)* s) my_strlen;

void load() @trusted
{
    void* handle = dlopen("libc.so.6", RTLD_LAZY);
    my_strlen = cast(typeof(my_strlen)) dlsym(handle, "strlen");
}

void main() @safe
{
    load();
    writeln(my_strlen(new char('z'))); // Buffer overrun
}

The existing error message is:

Error: `@safe` function `D main` cannot call `@system` function pointer `my_strlen`

What would the new error message be for this code?

[Herringway]

No error. It would be the same error (but in load() instead of main(), if it weren't gagged by @trusted). You've clearly added @trusted to the function just to enable it to be used by @safe code, so I see no problem here.

[dkorpel]

Then you're definitely changing the meaning of the attributes. void load() is a safe interface here, the use of @trusted is currently valid. With the proposed new semantics, how would I express "the loading function has a safe interface but the returned functions don't"?

[Herringway]

The loading function does not have a safe interface. It's setting up function pointers that aren't safe to use. Creating a function pointer is declaring your intent to call it later, so it should be treated as if it were being called where it's created. By marking the loading function @trusted you are deliberately opting out of those checks.

[dkorpel]

So if you load a plain function pointer in a nothrow context, and then later call it in a try { ... } catch (Exception e) body, then still your entire call chain up to main must be stripped of nothrow because the compiler has to conservatively assume the pointer gets called anywhere in your program. void function() load() nothrow becomes an impossible signature.