On Wed, 01 Dec 2010 12:43:38 -0500, Jesse Phillips
<jessekphillip...@gmail.com> wrote:
Jordi Wrote:
On the other side, in D, it is a hint to the compiler but it will only
use it if is verifiable. If that is the case, why do we need the "const"
keyword in the first place? The compiler can already verify that the
code is const and do the proper opimizations.
It can, unless the source is not available. Though it could probably
output the information when creating .di files.
This isn't practical. .di files are not object files, so they can be
altered too easily.
Note also that the compiler cannot do any optimizations for *const*
functions, it can only restrict access (useful for programmer).
Steve's solution would be on the side of "useful for the programmer,
enforced by the compiler, uselss for the compiler".
But it isn't enforced by the compiler. It can enforce that you only
modify things you claimed could be modified. But it can't enforce that
it is logically const. It could prevent the modifiable parts from
influencing the result, but then the requested caching isn't possible.
The current const regime cannot enforce that you cannot modify the logical
state of the object, because it does not know if any global variables are
part of the state.
Logically const cannot be enforced, and it cannot be prevented by const
alone.
A pure function enforces that you are not modifying external state. If
storage for non-state data is allowed inside the object (thereby enabling
logically const data), then special rules would need to be followed for
pure and immutable functions.
-Steve
