On Saturday, 22 June 2019 at 05:10:14 UTC, Yatheendra wrote:
It feels disingenous to want to call a caching object even
"logically" const. There has to be a scaffolding-based but
hopefully generic compromise. I haven't yet tested this belief,
but I believe "physical" const is of good use wherever it can
be applied.
On Friday, 21 June 2019 at 23:39:20 UTC, H. S. Teoh wrote:
The problem with this is that you cannot use const(Wrapper).
In particular, if you have a function that wants to document
that it does not mutate its argument, you cannot write:
auto func(in Wrapper data) { ... }
because const(Wrapper) does not allow lazy initialization.
...
...
"physical" const has to be applicable & good in many/most other
use-cases than caching (citation needed). Somehow, wanting to
call mutating code on logically const values sounds to be the
wrong want.
Lazy initialization sounds like it will be a good DIP :-)
Generate (once) on (first) read, just like copy (once) on (first)
write. But there are other ways.
Heavy computation called at most once: bite the bullet, eagerly
construct an immutable value ahead of time. "physical" const
might have just enough optimization opportunity to offset biting
the bullet.
Called more than once: same thing.
