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
| 
Permalink
Reply
