Index: doc/proposals/operator-defaults.md =================================================================== --- doc/proposals/operator-defaults.md (revision fc568163062dc14c2d5de7aa24dfe4d3f53f78fd) +++ doc/proposals/operator-defaults.md (revision fc568163062dc14c2d5de7aa24dfe4d3f53f78fd) @@ -0,0 +1,281 @@ +Operator Defaults +================= + +This proposal introduces a new syntax for requesting a default implementation +of an operator and the rules for generating them. + +This is to build on the implied relationships between operators. Most default +operators will be implemented in terms of other operators. As a fall-back +operators can try to figure out an intuitive definition from inspection of the +type's sue declaration. + +Syntax +------ + +The syntax for requesting a default implementation is part of function +definition. After the function signature (after the parameter list) instead +of putting the function body you declare it to be equal to default. + + box ?+?(box const & left, box const & right) = default; + +These can exist along side any forward definitions of the function, but would +conflict with any other complete definitions or deletions of the function. + +It could be valid syntax on any function, but possibly all non-operators would +report that no default implementation available. + +If default implementations are really popular and we don't need additional +information about the signature a more compact syntax could be added. + + default box( ?(), ?=?, ?!=?, ??, ?<=?, ?>=? ); + +Generation Strategies +--------------------- + +There exists a system around the default generation that selects how to +generate a given function if one can be generated at all. This section +describes that system and some of the logic behind it. + +There are two main strategies for generating an operator implementation. + +The first is to mimic the relationship between operators on the primitive +types by defining a new operator in terms of an existing operator on the same +type. For instance `++i` is equivalent to `i += 1`, so the generated +implementation will "look like" that. + +The second is to inspect the structure of the declaration to guess at what +the default implementation would be. Because of that it is dependent on the +kind of declaration, a structure doesn't have the same rules as an +enumeration. Also it is similar to the implicate definitions currently created +by the compiler and the generation methods for many are carried over. + +From these strategies a method of generation (a particular set of rules that +define an implementation from the type and existing functions) has to be +picked, but often there is more than on reasonable choice. In these cases they +are ordered and the first (best) one whose requirements is met is then used. +See "Circular Requirements" below for some exceptions and extensions to this +pattern. + +Generally the methods based on operators come first as they propagate any +unusual implementations from the explicate operators to the ones being +generated. If all of those fail then the intuitive definition based on the +declaration's shape is used. The general patterns in this area for the +different sue types follow. + +### Structures +Structures will usually apply the operation to each field, or when there are +two parameters the matching pairs of fields from each, and then combine the +results. + +This does require that the fields have certain operators defined on them. +In this respect it is still operator based generation, but we use inspection +on the structure to find out which operators to use. + +Also, for the purposes of default generation types declared with the +concurrency modifiers (coroutine, monitor and thread) are considered structs. +The default implementations should be the same as if you had written out the +extra field and functions by hand. + +### Enumerations +The two ways of using enumerations are considered. First as "one of" the +list options as in normal use, the second is as a set of flags where each +option represents a flag that may or may not be set. + +Currently there is no way to specify which nor does the system attempt to +guess by checking assigned values. There is one case where an operator could +have a meaningful default in both versions. If both are included then we can +try to pick one by scanning the enumeration to see what values its options +are given (a linear series or powers of 2) could be used. In all other cases +the definition that makes sense can be assumed. + +### Unions +Unions are the hardest to deal with because the instance does not show which +field in the union is being used. Because of that there are very few intuitive +definitions to use and the ones that do depend on bit-wise operations and only +if the union is made of primitive types. + +### Traits +Default operations are not supported on traits. A function implemented by the +default generation may be used to satisfy an assertion. However a default +implementation may not be requested on a polymorphic function. + +It could in theory, limiting to operation based generation and using the +operations available in the assertion list. There are a few problems: ++ Knowing the entire set of functions being generated is very useful in some + cases and this information is quickly lost with polymorphic functions. ++ The rules for choosing a generation method do not match how a polymorphic + function is selected so the results can be inconsistent. ++ It is easily to mimic with a polymorphic function already, writing out one + generic function and including it. + +Default Generation +------------------ + +Here are the generation methods. Unless otherwise stated they are listed in +priority order. That is the first one mentioned that a type fits (has all the +required operators or its form matches) will be used. + +The operator based constructions can be used on any sue type, those that +require a particular kind mention that. + +### Constructor: ?{} +Note that requesting any constructor to be generated counts as defining a +constructor for purposes of disabling the implicate constructors. There are +no operator based methods for generating constructors. + +For structures: For the zero argument constructor (aka the default constructor, +which takes just a reference to the value to construct) each field is +constructed with its zero argument constructor. For the copy constructor each +field is copy constructed from the same field in the copied structure. For +zero_t and one_t each field is also constructed from zero_t or one_t. + +For enumerations: For the zero argument constructor the value is set to 0 if +one of the enumeration options is 0 (or set to the first value in the enum). +For the zero_t constructor it is the same except the check is skipped (and no +or). The copy constructor is the same as memcpy. + +For unions: For the zero argument constructor of a union that is constructed +entirely of primitive types (or other types that zero argument construct to +all 0s) the union filled with 0s. For the copy constructor of a union of types +that all have trivial copy constructors memcpy is used. + +### Destructor: ^?{} +Requesting the default destructor should be the same as having it implicitly +defined. Destructors only have one signature and the intuitive definition for +that is the same as without the signature. + +Still it should be allowed for consistency. It also allows it to be forward +declared and then generated in a .cfa file. + +### Assignment: ?=? +Default assignment is only supported between two objects of the same type. +For structures it is field to field assignment. For enumerations and unions +of primitives or trivially copiable types it the same as memcpy. + +### Equality: ?==? ?!=? +Both equality operations can be implemented by negating the result of the +other operations. + +For structures: Equality can be implement by checking equality on each pair of +matching fields and taking the logical and of the results. Inequality can be +implemented by checking inequality on each pair of matching fields and taking +the logical or of the results. + +Both logical operations could be short circuiting. Without side effects it is +purely an optimization. + +For enumerations: Both operations are the same as on the underlying integral. + +For unions: If it is assumed that the different branches represent different +views of the same data and this data is primitive, than bit-wise comparisons +can be used. + +### Comparison: ?? ?<=? ?>=? +Less than can be implemented by flipping the arguments on greater than. +Greater than can be implemented by flipping less then. Less than or equal to +can be implemented by flipping greater than or equal to. Greater than or equal +to can be implemented by flipping less than or equal to. + +Less than or equal to can be implemented by using less than, equals and taking +the or of the results. Greater than or equal to can be implemented by using +greater than, equals and taking the or of the results. + +> The trick of negating comparisons is not used. As an example ? (boolean) not ?>=? unless the type is strictly ordered. For operator based +> overloads that might not be true in very reasonable implementations so it is +> not assumed. + +Opposite less than can be implemented as less than or equal to and not equal +to. Greater than can be implemented as greater than or equal to and not equal +to. + +For enumerations: Enumerations that represent one of all operations are the +same as on the underlying integral. Enumerations that represent a set of +options could replace less then with subset of and greator than with superset +of and use bit-wise masking to implement those operations. + +### Binary & Relative Assignment Operators: ?_? ?_=? +This applies to each operator in the form of `T ?_?(T, T);` for some type T +and has a matching relative assignment operator `T& ?_=?(T&, T)` where the +`_` in both is replaced by some string of operator characters. + +The binary operator can be created by copying the left argument, using the +relative assignment with the right argument and returning the updated copy. + +The relative assignment operator can be implemented by using the binary +operation to create a copy, then assigning the result to the left argument. +The left argument should then be returned. For the signature above it would +return by reference. The signature `T ?_=?(T&, T)` could also be supported in +which case it would return by copy. + +### Minus: -? ?-? +Unary minus can be implemented by subtracting argument from the value created +from zero_t. + +Binary minus can be implemented by negating (with unary minus) the right +argument and adding the result to the left argument. + +### Increment & Decrement: ++? ?++ --? ?-- +Either pre- operation can implemented by applying the post- operation and then +returning a reference to, or copy of, the updated value. Either post- +operation can be implemented by copying the argument, applying the pre- +operation to the original and returning the copy. + +Pre-increment can be implemented by using addition assignment by the value +constructed from one_t. Pre-decrement can be implemented by using subtraction +assignment by the value from one_t. + +Because many of the operations used have there own default implementations +(for example: ?+=? from ?+? or field-wise one_t construction) this list could +be expanded by replacing a function call with the default implementation for +that function. This might work for the post- operations generated from +relative assignment, the one_t constructed object and copying, but the logical +connection becomes weaker and weaker as that process continues. + +### Bit Manipulation: ?|? ?&? ~? ?<>? +No operation based construction is provided for bit manipulation operators. + +For enumerations that are considered sets of flags: And returns a set with all +flags set in both operand sets, or returns a set with all flags set that are +set in either operand sets and not returns a set with all flags set that are +not set in the operand set. + +> And it would be possible to actually implement this for any sized type and +> just do the bitwise operation and trust the user that it makes sense if they +> request it. + +Also for set enumerations, the signature `T ?<