Index: doc/proposals/user_conversions.md
===================================================================
--- doc/proposals/user_conversions.md	(revision 5ff188f3cd236584cfa7f3b12ea210fdd51bde8a)
+++ doc/proposals/user_conversions.md	(revision ee1638951c419507b01213df65b264961d569d7f)
@@ -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 
