How often I should be using const? Is it useless/overrated?

[H. S. Teoh]

On Fri, Nov 18, 2022 at 11:51:42AM +0000, thebluepandabear via 
Digitalmars-d-learn wrote:
> A question I have been thinking about whilst using D is how 
> often I
> should be using const.

You should use it as often as you need to use it, and no more.  
If you
don't need to use it, don't use it.


> Many people claim that all variables should be const by 
> default, but
> whether or not it is really needed is debatable and oftentimes 
> making
> everything const could cause readability issues and make the 
> code more
> complex.

You're looking at it the wrong way.  The kind of issues having 
const
would solve is like when your function takes parameters x, y, z, 
and
somewhere deep in the function you see the expression `x + y*z`. 
If x,
y, and z are const, then you immediately know what the value of 
this
expression is.  However, if they were not, then you'd have to 
trace
through all of the preceding code to figure out whether their 
values
have changed, and how they have changed.  The former makes the 
code
easier to understand, the latter adds complexity to understanding 
the
code.

Now if you have a variable that's expected to change a lot, like 
an
accumulator of some complex calculation, then it makes no sense 
to make
it const.  Just modify it; you already have to understand most of 
the
code to figure out how the value is derived anyway, so having 
fewer
variables would actually make it easier to understand.  In this 
case,
using const is just counterproductive.

IOW, if const makes your code easier to understand and maintain, 
then go
for it.  If you're finding that you have to jump through hoops in 
order
to make your variables const, then probably it's *not* a suitable 
usage
in that case.


> I also wonder how important const really is, like 99% of the 
> time you
> will know when your variable will be changed, and even when a 
> variable
> changes it's not like it is the end of the world.

It totally *can* be the end of the world, if your variable is
controlling the launch of nuclear missiles, for example. :-P  
Having a
variable change when you don't expect it to -- that's a frequent 
source
of bugs and hard-to-understand code.  Again I say, it depends on 
what
it's being used for.  If it's used to hold a logically fixed value
(e.g., function argument passed from the caller that logically 
doesn't
change) then you want to use const.  But if you're using it to 
hold a
temporary value that's expected to change, then what's the point 
of
jumping through hoops just so you can brag "look, ma! my 
variables are
all const!"?


> Also, there is no real end to how much variables can be const.
> Oftentimes -- interestingly -- in popular repos I don't even 
> see const
> being used, this is what confuses me.
[...]

Because, honestly, const in D is a pain.  The reason is that D's 
const,
unlike const in C or C++, is transitive, meaning that if some 
object X
is const, then everything X refers to is also automatically 
const.  OT1H
this is wonderful: this means the compiler can actually make 
guarantees
about const and enforce it. You cannot just cast it away 
willy-nilly
without invoking UB, so the compiler can make optimizations based 
on the
assumption that some value never changes.  OTOH the fact that it's
transitive means that even if you have one tiny bit of data 10 
hops down
the line that you want to modify, you can't do it.  This greatly 
narrows
the applicability of const in D.  It's physical const, and cannot 
be
made logical const.

IME, const in D is mostly applicable to what I call "leaf node" 
data
structures: low-level structures where you're mostly dealing 
directly
with the underlying data or maybe 1-2 levels of abstraction away 
from
the physical data.  Once you get past that to higher level code, 
const
quickly becomes a giant pain to work with.  You cannot, for 
example,
lazy-initialize const data -- because that means you have to 
modify it
after the reference is already initialized, which is UB.  You 
cannot
cache data -- because you need to initialize the data when it's
referenced for the first time, and you need to set a flag to 
indicate
that the data is cached so that you don't have to load it again. 
There
are ways of working around this, but they are dirty and annoying 
to use.

In my own code, I rarely bother with const, except for the lowest 
levels
of code: modules that don't depend on anything else, so the scope 
is
easier to control and the number of situations to support is 
limited
enough that workarounds don't generate exponential amounts of
boilerplate.  In higher-level code I rarely bother with const. It 
often
excludes things you often do with complex code -- like caching, 
lazy
initialization, etc..  And errors with const in high-level code 
can
sometimes be a pain to track down -- you declare something const 
and
some leaf-node module 5 levels of abstraction down fails to 
compile.
Why?  You have to chase the code down 5 levels of abstraction to 
find
out.  It's just not worth the trouble.


Having said all that, though, one place where const/immutable 
really
shines in D is strings: because strings are defined to be
immutable(char)[], that means taking substrings never has to 
copy. This
saves a LOT of busywork copying bits of strings all over the 
place --
which you have to do in C/C++ because there char arrays are 
mutable, so
to make sure your substring doesn't unexpectedly mutate from 
under you,
you make a copy of it.  This leads to far more allocations than 
are
strictly necessary to perform some operation.  In D, you can 
freely
slice the strings as much as you want, and you're guaranteed that 
none
of them will unexpectedly mutate from under you.  None of them 
require
an allocation, and so are more efficient in string-processing 
code.


T

--
Маленькие детки - маленькие бедки.