Logical const

[Steven Schveighoffer]

On Tue, 30 Nov 2010 10:06:40 -0500, Don <nospam at nospam.com> wrote:

> Peter Alexander wrote:
>> D does not support logical const due to the weak guarantees that it  
>> provides.
>>  So, without logical const, how are D users supposed to provide lazy  
>> evaluation and memoization in their interfaces, given that the  
>> interface should *seem* const, e.g.
>>  class Matrix
>> {
>>   double getDeterminant() const { /* expensive calculation */ }
>> }
>>  If it turns out that getDeterminant is called often with the raw  
>> matrix data remaining unchanged, how can we add caching to this class  
>> without rewriting the const-ness of all code that touches it?
>>  And how do we write generic code when it's practically impossible to  
>> determine const-ness from a glance? e.g. getDeterminant looks like it  
>> should be const, but wouldn't be if it had caching, so writing generic  
>> code that uses getDeterminant would be very difficult.
>
> What are the use cases for logical const? Are there any other important  
> ones, apart from caching?

Being able to associate data with an object/struct without owning the  
data.  Deep in this thread I give an example of having a widget who knows  
its location and knows how to draw itself in that location.  Such a  
function cannot be marked const even though no widget data is changed,  
since the draw function is not const.  But the Widget doesn't own the  
location, it's just referencing it.

At that point, const moves from compiler-verified to documentation only.

-Steve