Why do we have transitive const, again?

[Jonathan M Davis]

On Friday, September 23, 2011 18:52:23 Mehrdad wrote:
> On 9/23/2011 3:56 PM, Jonathan M Davis wrote:
> > The complaints have generally been about the lack of logical const and
> > the inability to cast away const and modify variables _not_ about
> > transitiveness. I'm not say that there have been _no_ complaints about
> > the transitiveness about const, but I can't recall even _one_ issue
> > with it at the moment. It's the lack of logical const that's generally
> > complained about and has shown itself to be a major blocker for const
> > in some cases. - Jonathan M Davis
> 
> But the only reason logical const is an issue is indeed the fact that
> const is transitive.
> 
> To illustrate, I run into problem almost every other time I use D, and
> to me it's *only* a problem because source is const:
> 
> class MyRange : InputRange!char
> {
>       char peeked;
>       InputRange!char  source;
>       char front() const
>       {
>           // How do I lazy-load the value?
>           if (peeked == '\0')
>           {
>               peeked = source.front;
>               // ERROR, popFront isn't const...
>               source.popFront();
>           }
>           return peeked;
>       }
> }
> 
> If this isn't because of transitivity, then what is it? If only source
> wasn't implicitly const (and it wouldn't be in C++, since it'd be a
> const pointer to a non-const object) then this would be a piece of cake.
> 
> I run into this problem and similar ones so often that it's driven me
> away from D, as much as I was a fan. If you have a nice solution then
> please let me know.

Then the lack of logical const is really your issue, not the transivity. 
Granted, logical const would be less of an issue if const weren't transitive, 
but ultimately, it's the fact that there is no way to alter a const variable 
without subverting the type system that's your problem.

If you don't care about purity, it _is_ possible to have caching and lazy 
loading, but it's a bit ugly IMHO. If you have an AA outside of the object, 
you can cache the value you want in _it_. If the value isn't in the AA, then 
it still needs to be calculated, and if it _is_ in there, then you can just 
grab it from there. Voila, lazy loading and caching. But you lose purity, and 
it moves the data outside of the class itself (or at least out of the class 
instance - it could be a static variable in the class). So yeah, it kind of 
sucks, but it _is_ doable.

So, is the fact that D's const does not allow for any kind of caching or lazy 
loading the only issue that you're really seeing with const (beyond 
implementation issues)? It _is_ an issue, and the transivity does make it 
worse, since more stuff is const than would be otherwise, but are there other 
issues beyond that?

I think that it would be great if we could find a solution to lazy loading and 
caching so that it works with const, but I fear that at this point, that that 
is relegated to D3 unless someone can come up with a very clever solution that 
is backwards compatible. On the bright side though, it _does_ give us plenty 
of time to come up with a solid solution, since D3 won't be started for quite 
a while.

But ultimately, it's a matter of tradeoffs. Do the benefits of transitive const 
outweigh the loss of caching and lazy loading? For most programs, I believe 
that the answer is definitely yes (especially since it helps enable immutable), 
but since it _is_ a tradeoff, it's definitely true that some programs will lose 
out on the ability to use const in places where it might be desirable.

- Jonathan M Davis