[Issue 1983] Big Hole in Const System

[Frits van Bommel]

Janice Caron wrote:
>>  ------- Comment #1 from fvbommel at wxs.nl  2008-04-10 05:55 -------
>>  IMHO the problem here isn't the type of (&a.x) but the fact that it's allowed
>>  to compile at all.
> 
> Same thing. You just stated the problem differently.
> 
>     a.x = 2;
> 
> won't compile because a.x is typed const. Wheras
> 
>     (&a.x)(2);
> 
> will compile because (&a.x) is not typed const. The fact that it
> compiles is a /symptom/.

I disagree. As long as (&a.x) for mutable a and const x (and similar 
cases with invariant, etc.) doesn't compile, there's no need for 
'delegate() const'. See below.

 > We can treat the symptom, but I'd rather
> treat the disease. To treat the disease, the type system must allow
> types such as
> 
>     ReturnType delegate(Params...) const
> 
> to exist. Likewise
> 
>     ReturnType delegate(Params...) invariant
> 
> and eventually, we're even going to need
> 
>     ReturnType delegate(Params...) invariant pure

I can see the need for the pure variant, but not any of the others. I 
see no reason to distinguish between a delegate to a const method and 
one to a normal method, as long as you can't create a delegate to a 
method using an object of inappropriate constness.
Who (except again in case of 'pure') cares if the object pointed to by 
the void* .ptr changes if the method is called? Obviously whoever 
created the delegate must have had mutable access to it[1] (since that 
should IMHO be the only way to create such a delegate), so they have 
every right to create a delegate that mutates it.

In other words: since you don't have a useful explicit reference to the 
object, who cares if it's const or not?


[1] Or invoked undefined behavior by somehow casting away const, in 
which case it doesn't matter *what* happens.