How are delegate attributes in fn signature inferred?

[Adam D Ruppe]

On Monday, 23 May 2022 at 13:44:53 UTC, wjoe wrote:
>   i.construct((ulong i) {return cast(int)(i+i);}).print;

You can actually make this work with `construct!(int[])` rather 
than plain `construct`. This is a (really annoying) deficiency in 
dmd's implementation. (that sdc solved btw proving it can be done 
just dmd never bothered)

> Where's **pure nothrow @nogc @safe** coming from?

That's because it is a delegate literal, so it automatically 
figured out the tightest thing that works (this is also why it 
came as `function` instead of `delegate`, since it doesn't use 
any local variables from the enclosing function, it doesn't need 
the delegate pointer either).

But all those implicitly convert away so it doesn't really 
matter. The type system allows this, just the crappy 
implementation can't handle inferring that R when it is mentioned 
both as R r *and* ElementType!R - the stupid compiler sees 
ElementType!R and bails out.

Thus why you have to help it by telling the type when 
instantiating it

   i.construct!(int[])((ulong i) {return cast(int)(i+i);}).print;