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.
