Fully transitive const is not necessary

[Steven Schveighoffer]

"Janice Caron" wrote
> On 03/04/2008, Steven Schveighoffer wrote:
>>  For example, if I have a function that looks like this:
>>
>>  int[] calculateSomeValues(const(Calculator) c);
>>
>>  written by some other developer who says "I won't be changing c, and c
>>  defines that f is const, so I'll declare that c is const".
>
> The difference between Calculator and CachingCalculator is a bit like
> the difference between File and BufferedFile. We all /know/ that file
> access is slow, and so buffering speeds things up. Ditto here. That
> other developer should have written
>
>    int[] calculateSomeValues(CachingCalculator c);
>
> and if they were dumb enough to use an underpowered class, then don't
> call their function.

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.

And the "don't call badly defined functions" scheme is not always possible.

>
>
>
>>  and inevitably, they [other people] will have
>>  incorrectly implemented it
>
> One doesn't introduce new language features on the assumption that
> other people will incorrectly implement other language features.

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.

> It's just education, that's all. When using D, you program "the D
> way". And that means, you don't declare something const, if you know
> that bits of it are going to change. That's how it works in D. Look at
> it like this - D mandates good habits.

D const mandates workarounds, which I do not consider to be good habits. 
Any time a language feature that is supposed to help developers work 
together makes the language harder to work with, that's a red flag to me. 
I'm not saying I disagree with const, I'm just saying its absolute 
transitivity is not preventing us from using logical const-like features, 
and so the notion that it is required, or at least the notion that logical 
const won't work, is false.

-Steve