https://issues.dlang.org/show_bug.cgi?id=21518

          Issue ID: 21518
           Summary: delegates not checked for attribute match in const
                    array parameters
           Product: D
           Version: D2
          Hardware: All
                OS: All
            Status: NEW
          Severity: major
          Priority: P1
         Component: dmd
          Assignee: nobody@puremagic.com
          Reporter: qs.il.paperinik@gmail.com

A function taking a slice of delegates as a parameter that is annotated @safe can be fed @system operations. An example for taking a slice of delegates is lazy variadic functions.

Consider:
    void func(const void delegate() @safe [] paramDGs...) @safe
    {
        if (paramDGs.length > 0) paramDGs[0]();
    }

A call to func(arr) should not compile when arr contains @system delegates and is typed accordingly. But the compiler accepts this:

    const dg = delegate() @system { int* p; int x; p = &x; };
    // dg explicitly contains un-@safe operations to be sure.
    const(void delegate() @system)[] arg = [ dg ];
    func(arg); // illegal call, not caught
    func(dg); // illegal variadic call, caught properly

Replacing `delegate` by `function` everywhere, the compiler catches the type mismatch.

In the declaration of `func`, `in` instead of `const` yields the same result with and without `-preview=in`. However, replacing `const` with `immutable` everywhere makes the compiler catch the illegal call. Pushing down const one level of indirection, i.e. const(void delegate() @safe)[] instead of const(void delegate() @safe []) does not help. Pushing down const and replacing it with immutable makes the compiler catch the illegal call.

For some reason, const and delegate conspire to trick the compiler into accepting attribute mismatches. This issue is not directly related to @safe, the issue arises for pure, too.

--