Inherited const when you need to mutate

[Sean Kelly]

On Jul 11, 2012, at 12:58 AM, Don Clugston <dac at nospam.com> wrote:

> On 10/07/12 19:13, H. S. Teoh wrote:
>> On Tue, Jul 10, 2012 at 06:48:51PM +0200, Timon Gehr wrote:
>>> On 07/10/2012 06:45 PM, H. S. Teoh wrote:
>>>> Yeah, this is logical const. Unfortunately, D doesn't have logical
>>>> const.
>>>> 
>>> 
>>> Then why on earth is druntime acting as if it does?
>> 
>> Y'know, this brings up an interesting question. Do methods like toString
>> _need_ to be const? That is, _physical_ const?  Or are we unconsciously
>> conflating physical const with logical const here?
>> 
>> Yes, certain runtime operations need to be able to work with const
>> methods, but I wonder if those required const methods really belong to a
>> core set of more primitive operations that guarantee physical const, and
>> perhaps shouldn't be conflated with logical operations like "convert
>> this object to a string representation", which _may_ require caching,
>> etc.?
>> 
>> Or perhaps application code want to be defining their own non-const
>> versions of certain methods so that they can do whatever they need to do
>> with logical const, without worrying about breaking physical const-ness.
>> 
>> I'm starting to think that D's hardline approach to const is clashing
>> with the principle of information hiding. Users of a class shouldn't
>> _need_ to know if an object is caching the value of toString, toHash, or
>> whatever it is. What they care for is that the object doesn't visibly
>> change, that is, logical const. Binary const implies logical const, but
>> the implication doesn't work the other way round. While it's nice to
>> have binary const (strong, enforceable guarantee), it breaks
>> encapsulation: just because a class needs to do caching, means its
>> methods can't be const, and this is a visible (and viral, no less)
>> change in its external API. What should just be an implementation detail
>> has become a visible difference to the outside world -- encapsulation is
>> broken.
>> 
>> I don't know how to remedy this. It's clear that physical const does
>> have its value -- it's necessary to properly support immutable, allows
>> putting data in ROM, etc.. But it's also clear that something is missing
>> from the picture. Implementation details are leaking past object APIs,
>> caching and other abstractions can't work with const, etc., and that's
>> not a good thing.
>> 
>> 
>> T
> 
> I think you're right.
> Something I wonder about, though, is how many different use cases are we dealing with?
> 
> Suppose we had a caching solution (you could think of it as @cached, but it could be done in a library). The user would need to provide a const, pure function which returns the same value that is stored in the cache.
> This is enforceable. The only way to write to the cache, is by calling the function.
> 
> How far would that take us? I don't think there are many use cases for logically pure, apart from caching, but I have very little idea about logical const.

Lazy loading, which I suppose is a type of caching. Use of synchronization primitives should be allowed as well. We sidestep this because the synchronized statement sidesteps const restrictions.