What operations are supported by default between two data classes with the same fields in different orders? What implicit conversions are allowed between aggregates, such as arrays, tuples, and data classes?
- Comparison operators more generally were added to Carbon in proposal #702: Comparison operators
- An initial take on these questions was originally in proposal proposal #561: Basic classes: use cases, struct literals, struct types, and future work but postponed until we had agreement on the right approach.
- The discussion that eventually reached an agreement took place in question-for-leads issue #710: Default comparison for data classes
We propose that we should permissively allow operations between data classes and other aggregates with different field orders and types where we can. Field order in data classes is salient, but mostly determines the order that operations are performed. The only case where different field orders will forbid an operation is with ordering comparisons, where the field order determines the answer returned, not just the order of execution.
Changes have been made to:
These changes are intended to apply to all aggregate types, including arrays.
This proposal advances Carbon's goals:
- Software and language evolution: This proposal allows changes to field order and type to be made incrementally.
- Code that is easy to read, understand, and write: This proposal provides useful and expected facilities for data classes and other aggregate types by default.
Alternatives were considered in:
We considered not making field order significant in struct types, making them into unordered collections of named fields. This view is consistent with order not being significant in initializers in prior class proposal #561. This had a number of consequences:
- Users would not have control over the order of operations performed field-by-field, such as comparisons, unless they use a nominal class type and implement those operations explicitly.
- Order comparison operators, like
<and<=, would not be supported. We considered defining an unspecified-but-fixed ordering, for use in things like binary search, accessed in some other way than the ordinary comparison operators.
Ultimately, we decided that field order was a salient property of struct types, at least determining the layout of the data in memory, and we should use it to determine the order of operations and how to compare lexicographically.
Reference: See
this comment by geoffromer on #710.
Rather than picking the left-hand argument's field order when the orders were different, we considered requiring the field order to match when performing all comparisons, including equality comparisons. An explicit conversion to a common type would be required to perform a comparison when the field orders did not match.
The current proposal is more convenient for users, and has the property that
executing a = b results in the condition a == b being true, even when a
and b have different field orders. We also believed that operations like
assignment between structs with different field orders would be more efficiently
implemented using field-by-field assignment rather than a conversion to the
left-hand type followed by assignment, and so it was natural to support the
former directly.
We expected a lot of code trying to pass values between functions using
different field orders would use destructuring instead of direct conversion. As
a result, we thought it might be safer to require explicit conversions to avoid
silently converting, say, 10,000 i8 values to i64.
However, there were some important use cases for performing the conversion
implicitly, such as (1, 1) converting to an (i8, i8) value. We did not want
rules that distinguish this case from other implicit conversions, for
simplicity. Similarly, we wanted the set of conversions to be consistent across
aggregate types, including tuples, arrays, and data classes. We can amend these
rules in the future to address cases that are surprising to users in practice.
Reference: See
this comment by chandlerc on #710.