[New DIP] Attributes for Higher-Order Functions

[Bolpat]

Functions that have function pointers or delegates as parameters cannot be integrated well in pure, nothrow, @safe, and @nogc code. This DIP proposes to adjust the constraints that the mentioned attributes impose. It will only affect aforementioned functions with function pointers or delegates as const or immutable parameters.
The goal is to recognize more code as valid that factually behaves in accordance to the attributes.
An example is this:

struct Aggregate
{
    void toString(const void delegate(char) sink) @safe { … }

    string toString() @safe
    {
        string result;
        void append(char c) { result ~= c; }
        toString(&append); // append is inferred @safe
        return result;
    }
}

Notice how sink is not annotated @safe, but it is declared const. The key observations of this DIP are that because it is const, any call like sink('c') can only execute the delegate passed to it (sink cannot e.g. be reassigned), and thus, the toString() function has full knowledge about whether the argument &append that binds to sink is @safe.
This DIP proposes

• that the first toString overload allowed to call its parameter sink even if not annotated @safe — and
• that the call toString(&append) is only @safe when both the called function toString and the argument &append are @safe.

Calling toString with a @system sink is also valid, but the call will be considered @system since the condition that the argument be @safe is violated.

These rules allow making lazy a lowering to a delegate type. Binding of arguments can still be done by implicitly embedding them in a delegate; a general implicit conversion from expressions to delegates is not necessary, but would work equally well.

Furthermore, when making e.g. @safe the default, the changes proposed by this DIP allow for an especially smooth transition path for higher-order functions that is not available otherwise.

Delegates and function pointers with different attributes are compatible yet different types. For method overriding to behave as expected, overriding with contravariant parameters must be available to some degree.

[Geod24]

I have multiple issues with this DIP. I'll admit I stopped around 2/3rd in.

First, the form of the DIP makes it very hard to understand:

1. The abstract is a bit short and vague, and the DIP jumps immediately into terms and definition;
2. The terms and definition are not used consistently within the document;
3. The language of the DIP is uneven, sometimes colloquial, sometimes formal, confusing the reader even more;
4. There is almost no code example: What becomes legal ? What becomes illegal ?
5. The DIP re-invent existing terminology instead of using pre-established one;

My understanding is that the DIP suggest to simply ignore attributes on callables in higher-order function, that is, allow the following:

void function (void function (int) fp) @nogc @safe pure nothrow
{
    fp(42);
}

Is that so ?

[mdparker]

@Bolpat I emailed you about this DIP some days ago. If you don't find it, could you please email me at aldacron@gmail.com so we can discuss it? Thanks!

[Bolpat]

@mdparker, I answered your email just now. In short, let's move on with this.