Index: doc/proposals/tagged-struct.txt
===================================================================
--- doc/proposals/tagged-struct.txt	(revision a4b3525b6d09c48f128de8cc65c7c83e671ed7b3)
+++ doc/proposals/tagged-struct.txt	(revision 5bd0aad2eb20d7e1f1b3a2f5e19678c448dd7e13)
@@ -71,4 +71,9 @@
 should be possible to do during linking.
 
+If a generic/polymorphic type is tagged its tagged would then be shared
+between all applications of that generic. Internal tags could be used to
+seperate these structures again, however it seems in most cases simply using
+the existing type parameters should provide the needed information.
+
 
 Traits:
@@ -102,21 +107,57 @@
 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
+Which brings us to "tagged 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.
+possible values of the union must be of that tagged type or a child type. If
+the tagged type is omitted then they must all be tagged but of any tagged
+type.
+
+As a short cut union_instance->type might get the type object of the loaded
+value. It should always be the same operation regardless so it saves
+abritarly picking a branch of the union to get the type object.
 
 
-Custom Type Objects (Extention):
+Type Objects Fields (Extention):
 
-Some method to define type objects used within a tree of types. One option is
-to allow the tree's type object to be specified by the tree root. It would
-then have to be filled in for each type in the tree, including the root.
+Adding fields to the type object allows data to be shared between instances
+of the same type. Such behaviour could be mimiced by creating a lookup
+function on the type object pointer, but this may be cleaner and more
+efficient.
 
-The only required field is the parent field, a pointer to the type object's
-type. (This is also the only required field on the tagged structure itself.)
+The type object fields follow similar rules to the fields on the tagged
+objects themselves, they must be additive. So any fields present on a
+type object will be present (and in the same place) on all of its children.
 
-A further extention could allow expanding type objects, so child types could
-append fields to their parent's feild list. They might need their own type
-objects at that point, or maybe static checks will be enough to see the
-minimum field list.
+This does mean that many type object structure types will have to be auto
+generated, and traversing up the tree might get a little wierd. That could
+be symplified by only allowing the root type to specify fields on the type
+object, so that the type object is consistant throughout that particular tree.
+And hence the type_object pointers would also be consistant as the type they
+point to would never change.
+
+struct Example tagged {
+	tagged char const * const type_name = "Example";
+	int data;
+};
+
+Creates a tagged structure that has no parent, stores an integer and the type
+object also has an extra field that stores a string on the type object.
+This can be accessed by using member access on the type object, as a regular
+structure.
+
+Type object fields will have to allow initialization on their declaration,
+and declarations of children as well, as they are not assotiated with the
+later instances of the tagged structure.
+
+	...
+	tagged void (*dtor)(tagged Example * this);
+	...
+
+Sub-Extention, not sure how it would work but some way to have a "dynamic"
+field that is considered the type of the current tagged struct might be useful
+for things like specifying a deconstructor. In this case, the following code
+will clean up any child type of Example:
+
+Example * ex = get_some_example();
+ex->type->dtor(ex);