If you need something which behaves like a group of independent-but-related variables bound together with duct tape (E.g. the coordinates of a vector), use an exposed-field structure. The fields of an exposed-field structure are mutable when the structure is stored in a mutable location, and immutable when the storage location is stored in an immutable location.
Because an open-field structure behaves like a bunch of independent-but-related variables, some people who think everything should behave like an object deride them as "evil". I would posit that although open-field or otherwise-mutable structures are generally not suitable in places requiring something that behaves like an object, they are a perfect fit in places where one will need bunches of variables stuck together with duct tape.
It's possible to use immutable class objects to hold bunches of independent-but-related values. It can even be advantageous in cases where composite values (i.e. particular combination of values) will be passed around much more frequently than they are created. On the other hand, if code which holds a reference to a vector (34,39) wants to hold a reference to a vector whose x component is one larger, it won't be able to simply increment a field (as it could with a structure) but must instead create an entirely new vector object (35,39). The performance cost of doing this won't be a problem if one never has to perform such operations repeatedly within an inner loop. On the other hand, if a program would frequently execute significant loops whose primary purpose involves constructing slightly-modified versions of objects, the time required to construct such objects could become a substantial fraction of overall execution time.