DIP30, delegates more destruction for your pleasure

[Timon Gehr]

On 03/14/2013 05:14 PM, deadalnix wrote:
> On Thursday, 14 March 2013 at 16:01:28 UTC, Timon Gehr wrote:
>> On 03/14/2013 04:41 PM, deadalnix wrote:
>>> ...
>>>
>>> DIP updated.
>>>
>>
>> Using a vastly different set of allowed/disallowed cases. Every
>> delegate type must implicitly convert to unqualified. Otherwise
>> attribute inference may break code that would be valid without.
>> (this has to work differently with explicitly-typed contexts, because
>> those are not opaque.)
>>
>
> Can you elaborate on that please ? I fail to see the problem.
>

int foo(int delegate() dg){ return dg(); }

void main(){
     foo(delegate()=>2); // error, int delegate()pure immutable
                         // does not convert to int delegate()
}


>> I favour neither, but your approach removes all guarantees on const.
>
> Such guarantee can already be broken with aliasing so nothing new.
>

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

>>> inout const isn't a valid type qualifier so I dropped it.
>>
>> I consider that a DMD bug.
>
> What would be the semantic ?

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.