Index: doc/proposals/user_conversions.md =================================================================== --- doc/proposals/user_conversions.md (revision 5ff188f3cd236584cfa7f3b12ea210fdd51bde8a) +++ doc/proposals/user_conversions.md (revision d286cf68892dfb231fb65f0127f47f3d593ac9f1) @@ -5,20 +5,16 @@ There is also a set of _explicit_ conversions that are only allowed through a cast expression. -Based on Glen's notes on conversions [1], I propose that safe and unsafe -conversions be expressed as constructor variants, though I make explicit -(cast) conversions a constructor variant as well rather than a dedicated -operator. +I propose that safe, unsafe, and explicit (cast) conversions be expressed as +constructor variants. Throughout this article, I will use the following operator names for constructors and conversion functions from `From` to `To`: - void ?{} ( To*, To ); // copy constructor - void ?{} ( To*, From ); // explicit constructor - void ?{explicit} ( To*, From ); // explicit cast conversion - void ?{safe} ( To*, From ); // implicit safe conversion - void ?{unsafe} ( To*, From ); // implicit unsafe conversion - -[1] http://plg.uwaterloo.ca/~cforall/Conversions/index.html - -Glen's design made no distinction between constructors and unsafe implicit + void ?{} ( To&, To ); // copy constructor + void ?{} ( To&, From ); // explicit constructor + void ?{explicit} ( To&, From ); // explicit cast conversion + void ?{safe} ( To&, From ); // implicit safe conversion + void ?{unsafe} ( To&, From ); // implicit unsafe conversion + +It has been suggested that all constructors would define unsafe implicit conversions; this is elegant, but interacts poorly with tuples. Essentially, without making this distinction, a constructor like the following @@ -26,5 +22,5 @@ multiplying the space of possible interpretations of all functions: - void ?{}( Coord *this, int x, int y ); + void ?{}( Coord& this, int x, int y ); That said, it would certainly be possible to make a multiple-argument implicit @@ -32,8 +28,8 @@ used infrequently: - void ?{unsafe}( Coord *this, int x, int y ); + void ?{unsafe}( Coord& this, int x, int y ); An alternate possibility would be to only count two-arg constructors -`void ?{} ( To*, From )` as unsafe conversions; under this semantics, safe and +`void ?{} ( To&, From )` as unsafe conversions; under this semantics, safe and explicit conversions should also have a compiler-enforced restriction to ensure that they are two-arg functions (this restriction may be valuable @@ -43,9 +39,16 @@ is convertable to `To`. If user-defined conversions are not added to the language, -`void ?{} ( To*, From )` may be a suitable representation, relying on +`void ?{} ( To&, From )` may be a suitable representation, relying on conversions on the argument types to account for transitivity. -On the other hand, `To*` should perhaps match its target type exactly, so -another assertion syntax specific to conversions may be required, e.g. -`From -> To`. +Since `To&` should be an exact match on `To`, this should put all the implicit +conversions on the RHS. +On the other hand, under some models (like [1]), implicit conversions are not +allowed in assertion parameters, so another assertion syntax specific to +conversions may be required, e.g. `From -> To`. +It has also been suggested that, for programmer control, no implicit +conversions (except, possibly, for polymorphic specialization) should be +allowed in resolution of cast operators. + +[1] ../working/assertion_resolution.md ### Constructor Idiom ### @@ -53,13 +56,14 @@ that we can use the full range of Cforall features for conversions, including polymorphism. -Glen [1] defines a _constructor idiom_ that can be used to create chains of -safe conversions without duplicating code; given a type `Safe` which members -of another type `From` can be directly converted to, the constructor idiom -allows us to write a conversion for any type `To` which `Safe` converts to: - - forall(otype To | { void ?{safe}( To*, Safe ) }) - void ?{safe}( To *this, From that ) { +In an earlier version of this proposal, Glen Ditchfield defines a +_constructor idiom_ that can be used to create chains of safe conversions +without duplicating code; given a type `Safe` which members of another type +`From` can be directly converted to, the constructor idiom allows us to write +a conversion for any type `To` which `Safe` converts to: + + forall(otype To | { void ?{safe}( To&, Safe ) }) + void ?{safe}( To& this, From that ) { Safe tmp = /* some expression involving that */; - *this = tmp; // uses assertion parameter + this{ tmp }; // initialize from assertion parameter } @@ -67,14 +71,46 @@ unsafe conversions. +Glen's original suggestion said the copy constructor for `To` should also be +accepted as a resolution for `void ?{safe}( To&, Safe )` (`Safe` == `To`), +allowing this same code to be used for the single-step conversion as well. +This proposal does come at the cost of an extra copy initialization of the +target value, though. + +Contrariwise, if a monomorphic conversion from `From` to `Safe` is written, +e.g: + + void ?{safe}( Safe& this, From that ) { + this{ /* some parameters involving that */ }; + } + +Then the code for a transitive conversion from `From` to any `To` type +convertable from `Safe` is written: + + forall(otype To | { void ?{safe}( To&, Safe ) }) + void ?{safe}( To& this, From that ) { + Safe tmp = that; // uses monomorphic conversion + this{ tmp }; // initialize from assertion parameter + } + +Given the entirely-boilerplate nature of this code, but negative performance +implications of the unmodified constructor idiom, it might be fruitful to have +transitive and single step conversion operators, and let CFA build the +transitive conversions; some possible names: + + void ?{safe} (To&, From); void ?{final safe} (To&, From); // single-step + void ?{safe*} (To&, From); void ?{safe} (To&, From); // transitive + What selective non-use of the constructor idiom gives us is the ability to define a conversion that may only be the *last* conversion in a chain of such. -Constructing a conversion graph able to unambiguously represent the full -hierarchy of implicit conversions in C is provably impossible using only -single-step conversions with no additional information (see Appendix A), but -this mechanism is sufficiently powerful (see [1], though the design there has -some minor bugs; the general idea is to use the constructor idiom to define -two chains of conversions, one among the signed integral types, another among -the unsigned, and to use monomorphic conversions to allow conversions between -signed and unsigned integer types). +One use for this is to solve the problem that `explicit` conversions were +added to C++ for, that of conversions to `bool` chaining to become conversions +to any arithmetic type. +Another use is to unambiguously represent the full hierarchy of implicit +conversions in C by making sign conversions non-transitive, allowing the +compiler to resolve e.g. `int -> unsigned long` as +`int -> long -> unsigned long` over `int -> unsigned int -> unsigned long`. +See [2] for more details. + +[2] ../working/glen_conversions/index.html#usual ### Appendix A: Partial and Total Orders ### @@ -153,5 +189,5 @@ convert from `int` to `unsigned long`, so we just put in a direct conversion and make the compiler smart enough to figure out the costs" - this is the -approach taken by the existing compipler, but given that in a user-defined +approach taken by the existing compiler, but given that in a user-defined conversion proposal the users can build an arbitrary graph of conversions, this case still needs to be handled. @@ -160,5 +196,5 @@ exists a chain of conversions from `a` to `b` (see Appendix A for description of preorders and related constructs). -This preorder corresponds roughly to a more usual type-theoretic concept of +This preorder roughly corresponds to a more usual type-theoretic concept of subtyping ("if I can convert `a` to `b`, `a` is a more specific type than `b`"); however, since this graph is arbitrary, it may contain cycles, so if @@ -192,5 +228,5 @@ and so is considered to be the nearer type. By transitivity, then, the conversion from `X` to `Y2` should be cheaper than -the conversion from `X` to `W`, but in this case the `X` and `W` are +the conversion from `X` to `W`, but in this case the `Y2` and `W` are incomparable by the conversion preorder, so the tie is broken by the shorter path from `X` to `W` in favour of `W`, contradicting the transitivity property