On Tue, 30 Nov 2010 10:06:40 -0500, Don <nos...@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
