Index: doc/proposals/tagged-struct.txt
===================================================================
--- doc/proposals/tagged-struct.txt	(revision f13ee31ce49b84afc3073ce57778d6ed16695e87)
+++ doc/proposals/tagged-struct.txt	(revision 1bc9dcb7380324924d59ecf1a921a40f6776c5e9)
@@ -11,9 +11,7 @@
 function call.
 
-Tags cannot be used on unions. This is because the different sides interact
-with the casts rather badly. There is a similarity with tagged unions still.
-Tagged structures also carry data to identify which out of several
-possibilies the object actually is. Although the possibilies are dynamic in
-this case.
+The name tagged structure comes from tagged union, which carries a value to
+say which of the possible values is currently stored in the union. The idea
+here is similar, however the possibilities are more open ended.
 
 
@@ -48,17 +46,16 @@
 parent type object.
 
-If the type field is given a simple name, then the user can easily access the
-type object. This might be useful depending on what sort of data is in the
-type object, especially if the data can be added to by the user in some way.
-Ironically one way to accomplish that is to make the type objects tagged
-themselves, but that recursion might not have a base case.
+The type field could be hidden (as best as C can hide it) or it could be
+visible to the user with easy access to allow the user to examine the type
+object directly.
 
-If the name is mangled and direct access to type objects is still wanted, then
-a function could be used to access the type object. Say get_type or get_tag
-instead of type or tag.
+Direct access is more useful if the data on the type-objects can change, other
+wise the build in function could handle all cases. Perhaps each root object
+can specify a type object to use or the type objects are themselves tagged,
+although there may not be a base case with the latter.
 
-If the data on the type object is set, than providing direct access may be
-unnessary. Instead the libraries or base code might be able to implement
-everything the data is for.
+In the simplest case the type object is a pointer to the parent type object.
+Additional data could be added, such as a name, or a function pointer to the
+destructor.
 
 
@@ -84,2 +81,15 @@
 
 bug#11 might require `bool dynamic_cast(T ** dst, U * src)` instead.
+
+
+Tagging Unions (Extention):
+
+Using this system as is does not really work if used on unions directly.
+No new options to the union can be added, as they must be able to upcast.
+Similarly, if options are removed, writing to an upcast union is invalid.
+To allow for growth each option would have to be a structure itself.
+
+Which brings us to "tagget struct union", ie. a union of tagged structures
+as opposed to tagging the union itself. This extention acts as a constraint.
+If unions are declared tagged instead of creating a new tagged type, all
+possible values of the union must be of that tagged type or a child type.
