Index: doc/proposals/tagged-struct.txt
===================================================================
--- doc/proposals/tagged-struct.txt	(revision 653f2c7bccaadf9f7ba7a78531e8c1783b34d230)
+++ doc/proposals/tagged-struct.txt	(revision 88177cfa68662ae38f89ec746c46e2e841797d56)
@@ -14,4 +14,6 @@
 say which of the possible values is currently stored in the union. The idea
 here is similar, however the possibilities are more open ended.
+
+Alternate names include virtual structure and abstract structure.
 
 
@@ -36,26 +38,36 @@
 their parent's fields to their field list so they can be upcast.
 
+The type field may be public, if it is then it can be accessed through a
+simple field access "instance.type". The type field would then be able to be
+used to access the type object, which contains the information for the type.
+It may just be a pointer to the type object "*instance.type", although a
+lookup function could also be used.
+
+
+Usage:
+
+The central feature for tagged structs is a checked cast between pointer types
+to the structures. A cast is successful if the true type of the pointed object
+is of the type being cast to or any of its children, otherwise the cast
+returns null.
+
+The type field should also allow for equality comparison of types.
+
+Currently, with only these operations (and similar features) the type field
+could be hidden and the operations given through helper functions. However
+if the type object has more complex (or even open ended) information in it
+than providing direct access becomes very valuable.
+
 
 Implemenation:
 
-Adding to the field list is a simple matter, should be doable during
-translation. The type field is just a pointer to a type object. With proper
-linking we can create a single unique instance of the type object for each
-declared tagged struct. The instance's address is used as an id for the type.
-It also holds data about the type, such as its parent's id/a pointer to the
-parent type object.
+Adding to the field list would have to be handled during translation. The
+simple act of adding declarations should not be difficult, althought it might
+take a bit of work to find the parent's declarations.
 
-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.
-
-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.
-
-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.
+Type objects are also simple in to generate, they should just be global
+(program lifetime) structures. Getting there to be exactly one instance of
+each allows the pointer to the structure to be used as the type id, and that
+should be possible to do during linking.
 
 
@@ -94,2 +106,17 @@
 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.
+
+
+Custom Type Objects (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.
+
+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.)
+
+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.