On Thursday, 14 March 2013 at 21:29:26 UTC, Timon Gehr wrote:
> int foo(int delegate() dg){ return dg(); }
>
> void main(){
>     foo(delegate()=>2); // error, int delegate()pure immutable
>                         // does not convert to int delegate()
> }
>

That make sense. The rules have to be loosened.

> Guarantees about const pure functions are lost. This is new. (Assuming a sound implementation.)
>

Yes. This is still better than hole in the type system IMO.

> It's just the combination of const and inout.
> It behaves in the straightforward fashion.
>
> inout is a wildcard standing for mutable, const or immutable.
>
> inout is mutable   => const(inout) = const
> inout is const     => const(inout) = const(const) = const
> inout is immutable => const(inout) = const(immutable) = immutable
>
> Hence const(inout) can be seen as a wildcard standing for const or immutable (but that's just derived information). Identifying const(inout) with const, as DMD does it, gratuitously loses type information.

I see. Type qualifier come at high cost, so I'm not sure.

On Thursday, 14 March 2013 at 21:29:26 UTC, Timon Gehr wrote:
> int foo(int delegate() dg){ return dg(); }
>
> void main(){
>     foo(delegate()=>2); // error, int delegate()pure immutable
>                         // does not convert to int delegate()
> }
>

OK, is it possible to consider naked delegate as const(void*) then ?

I think we should go for the usual instead of the covariant one as you propose. The regular will happen anyway and it is quite hard to keep everything together without introducing annoying rules.

For instance :

class Foo {
    delegate() bar;
}

Foo f = new Foo();
d.bar = { ... }
const g = f;
g.bar(); // ???