Idiomatic Way to declare C++ Immutable Classes

The way you proposed is perfectly fine, except if in your code you need to make assignment of RockSolid variables, like this:

RockSolid a(0,1);
RockSolid b(0,1);
a = b;

This would not work as the copy assignment operator would have been deleted by the compiler.

So an alternative is to rewrite your struct as a class with private data members, and only public const functions.

class RockSolid {
  private:
    float x;
    float y;

  public:
    RockSolid(float _x, float _y) : x(_x), y(_y) {
    }
    float MakeHarderConcrete() const { return x + y; }
    float getX() const { return x; }
    float getY() const { return y; }
 }

In this way, your RockSolid objects are (pseudo-)immutables, but you are still able to make assignments.

I assume your goal is true immutability -- each object, when constructed, cannot be modified. You cannot assign one object over another.

The biggest downside to your design is that it is not compatible with move semantics, which can make functions returning such objects more practical.

As an example:

struct RockSolidLayers {
  const std::vector<RockSolid> layers;
};

we can create one of these, but if we have a function to create it:

RockSolidLayers make_layers();

it must (logically) copy its contents out to the return value, or use return {} syntax to directly construct it. Outside, you either have to do:

RockSolidLayers&& layers = make_layers();

or again (logically) copy-construct. The inability to move-construct will get in the way of a number of simple ways to have optimal code.

Now, both of those copy-constructions are elided, but the more general case holds -- you cannot move your data from one named object to another, as C++ does not have a "destroy and move" operation that both takes a variable out of scope and uses it to construct something else.

And the cases where C++ will implicitly move your object (return local_variable; for example) prior to destruction are blocked by your const data members.

In a language designed around immutable data, it would know it can "move" your data despite its (logical) immutability.

One way to go about this problem is to use the heap, and store your data in std::shared_ptr<const Foo>. Now the constness is not in the member data, but rather in the variable. You can also only expose factory functions for each of your types that returns the above shared_ptr<const Foo>, blocking other construction.

Such objects can be composed, with Bar storing std::shared_ptr<const Foo> members.

A function returning a std::shared_ptr<const X> can efficiently move the data, and a local variable can have its state moved into another function once you are done with it without being able to mess with "real" data.

For a related technique, it is idomatic in less constrained C++ to take such shared_ptr<const X> and store them within a wrapper type that pretends they are not immutable. When you do a mutating operation, the shared_ptr<const X> is cloned and modified, then stored. An optimization "knows" that the shared_ptr<const X> is "really" a shared_ptr<X> (note: make sure factory functions return a shared_ptr<X> cast to a shared_ptr<const X> or this is not actually true), and when the use_count() is 1 instead casts away const and modifies it directly. This is an implementation of the technique known as "copy on write".

Now as C++ has developed, there are more opportunities for elision. Even C++23 is going to have more advanced elision. Elision is when the data isn't logically moved or copied, but just has two different names, one inside a function and one outside.

Relying on that remains awkward.

As of c++20, workarounds with getters is no longer needed.

You can now define your own copy-assignment operator for classes that contain const member objects without undefined behavior as of c++20.

This was undefined behavior prior to c++ and remains so for complete const objects but not non-const objects with const members.

https://stackoverflow.com/a/71848927/5282154