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
--
Маленькие детки - маленькие бедки.
Permalink
Reply
![Gravatar of []() {}()](http://www.gravatar.com/avatar/c9b169c2e6ca5b6e93e8fe8d4dad0ccd?d=identicon&s=32 "[]() {}()'s Gravatar profile"){kind=small}
![Gravatar of []() {}()](http://www.gravatar.com/avatar/c9b169c2e6ca5b6e93e8fe8d4dad0ccd?d=identicon&s=80 "[]() {}()'s Gravatar profile")