Fully transitive const is not necessary

[Janice Caron]

On 03/04/2008, Steven Schveighoffer <schveiguy at yahoo.com> wrote:
> They did not write CachingCalculator, I did.  They have Calculator, I wanted
>  to make a derived Calculator that uses caching and pass it into the
>  function.  What if the function simply took an interface?  The issue is that
>  the developer of that function is promising not to change c, which he
>  doesn't.  He cannot know how I will want to implement c.  In fact, given the
>  current const regime, the only correct choice in this is to NOT use const on
>  Calculator.f and therefore on any functions that take the calculator, as it
>  imposes too many restrictions on whoever is developing the type that will be
>  passed in.

Fair point.


> I'm not introducing a 'new' language feature.  Logical const is already
>  available through workarounds.  I'm suggesting we make it easier to express
>  logical const than by the hackish workarounds I've posted.

Presumably though, what you call a "hackish workaround" is exactly
what the compiler would have to implement for you if you got what you
want. That is,

    class C
    {
        mutable M m;
    }

would just be syntactic sugar for

    class C
    {
        private static M[const(C)] __cache;
        /* and appropriate functions to make it work */
    }

Maybe it's better to have all that explicit, rather than hidden, so
that it becomes obvious there's a price to pay, and that the lookup
time for an AA had better be insignificant compared to the cost of
computing an M or it's not worth it.