Inherited const when you need to mutate

[Don Clugston]

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.