Tuple and Tuple.Mutability

[cpurdy]

As discussed a week or so ago:

• Tuple has a Mutability mutability; property, with the potential values of Fixed, Persistent, and Constant. In all cases, adding or removing a field from a tuple is a persistent operation:it produces a new tuple, with a different type. For example, if I insert Boolean True as field 1 into the Tuple<String, Int> of ("hello", 42), I get returned a new Tuple<String, Boolean, Int>, with no changes being made to the original tuple, and regardless of the mutability setting on the original tuple.
• The Fixed mutability setting allows a caller to replace fields in place. So in the previous example, one could say: tup[0]="goodbye"; ++tup[1]; and the result would be ("goodbye", 43), with those changes occurring "in place" in the tuple (no new tuple(s) created). The original idea here is that a caller may need to change 15 different things in a tuple, so why create 15 new objects; while the idea itself is reasonable, in practice we have not actually encountered this use case.

As a thought experiment, if we dropped the mutability property altogether, we would be losing one thing that we do rely on: The ability for a tuple literal to be either deeply immutable (automatic if all its members are already immutable) or not (this occurs if any member is not already immutable) when it is created. Deep immutability is necessary to pass a tuple across a service boundary, for example. If we were to keep the freeze() method and drop the mutability setting, I posit that we'd still have everything that we rely on today.

@ggleyzer - please verify that the above understanding is correct.

Furthermore, if we remove it, and decide later that remove was a mistake, the default behavior is still the default behavior (both before and after removal, and thus also after removal vs. after adding it in at some future date long after having removed it). So we're not going to break things. (Famous last words.)

I'm comfortable with making this simplification of the Tuple interface. Any other opinions out there? (No one is currently using the feature, outside of our tests, so it's not going to get easier to make this change than right now.)

[ggleyzer]

I tend to agree with that idea. The only place we actually need Tuple is a reflective invoke() (we could use Object[] instead, but would be very inelegant). Would you like me to take a swing at the change?

[cpurdy]

Definitely! I'm comfortable with this change.

[ggleyzer]

Implemented by "Simplify Tuple API" commit