On Wednesday, 3 February 2016 at 06:11:07 UTC, H. S. Teoh wrote:
I still can't come up with a compelling use case that would justify using a const/immutable class member, that couldn't be done by some other means, though. Especially since we're talking about classes, we already have all the traditional OO mechanisms for controlling access to members - get methods, and so on, which are more flexible and adaptable to different use cases to begin with (e.g., can be overridden by derived classes, can implement custom access criteria not expressible by const/immutable, etc.), so I have a hard time justifying using const/immutable members instead.
You make a member variable const or immutable for the same reasons that you make a local variable const or immutable - it prevents accidental mutation and potentially makes it so that the compiler can optimize your code better. It's not necessarily the case that a const or immutable member variable is exposed in the API. It could be purely internal, or it could be exposed via a property function like any other member variable (I tend to think that member variable should never be exposed except for POD structs, since you lose out on flexibility if you do). But by simply making it const or immutable, you avoid certain bugs and potentially get faster code. IMHO, ideally, any variable that's never going to be mutated would be const or immutable, but that's not always possible for a variety of reasons (e.g. it doesn't play well with struct members, and const doesn't work well with all types).
- Jonathan M Davis
