Should I prefer immutable or const?

Jonathan M Davis via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Tue Nov 1 11:55:26 PDT 2016


On Tuesday, November 01, 2016 17:52:56 Nordlöw via Digitalmars-d-learn 
wrote:
> Should I always, when possible, prefer `immutable` over `const`?
>
> And does `immutable` increase the possibility of the compiler
> doing optimizations, such as common subexpression elimination?
>
> Or can the compiler infer `const` declarations to also be
> `immutable`?

That's not really something that can have a generally applicable answer.
const and immutable are similar but also very different, and which is
appropriate depends entirely on what you're doing.

If you're dealing with built-in value types, I would expect the code to be
100% identical, so whether you use const or immutable is a matter of
preference. I tend to use immutable, since it clearly indicates that the
value will never change, whereas for some types, const can change thanks to
another reference to the same data, but it doesn't actually matter for a
value type.

For reference types, if you want to use immutable, you're constructing the
object as immutable and using it as immutable everywhere. It's not a
temporary thing. In contrast, const could refer to either an immutable or
mutable object, so all you're really saying is that that code won't mutate
the object, not that its value won't change. It really doesn't make sense to
use const if you're intending that the object always be const. If you're
doing that, you might as well make it immutable, since you get implicit
sharing out of it, and the compiler can do optmizations based on immutable
that it can't do based on const, because it knows that the immutable object
will never change, whereas for a const reference to an object, it just knows
that _that_ code can't change it through _that_ reference. The same function
could very well be mutating that object via a mutable reference to the same
data.

Also, _very_ little in the way of optimizations can be done based on const,
so if you're looking to get the compiler to optimize stuff better, then
immutable is unquestionably better than const, but it does mean that that
data can never be mutated.

Really, const is for the cases where you want to accept mutable, const, and
immutable data without necessarily templatizing your function, and you don't
want the function to mutate the data. So, it's for passing off data to be
looked at but not mutated and not really for storing it. You _can_ store it
as const, but there's pretty much always going to be a mutable reference to
that data somewhere else, otherwise there wasn't much point in using const
over immutable.

Also, keep in mind that const is annoyingly restrictive in D, because it's
transitive and has no backdoors that aren't undefined behavior (unlike C++),
so slapping const on a lot of stuff is going to tend to prevent you from
doing useful things. In general, I'd expect stuff to be either mutable or
immutable and then primarily use templates to share code with const only
being used sparingly, but some folks do try and use const a fair bit -
especially when first coming from C++.

So, hopefully that's at least somewhat helpful, but to a great extent,
whether const makes any sense is highly dependent on what your code is
doing. And aside from specially designed types, immutable isn't likely to be
used much outside of value types of arrays, because not being able to ever
mutate under any circumstances doesn't usually work well with types unless
they were designed with that in mind.

- Jonathan M Davis




More information about the Digitalmars-d-learn mailing list