Index: doc/proposals/tagged-struct.txt
===================================================================
--- doc/proposals/tagged-struct.txt	(revision cdd1695f9fcbfaa783e678c6f8e2f739eb1069b3)
+++ doc/proposals/tagged-struct.txt	(revision cdd1695f9fcbfaa783e678c6f8e2f739eb1069b3)
@@ -0,0 +1,85 @@
+Proposal to add simple inhieritance to the language.
+
+Tagged structures allow for dynamic casting between types in a hierarchy.
+Children (rather pointers to) can be up-cast to their parents, a safe
+conversion that may recive language level support or even be implicate.
+Parents can be down cast to their children, which might fail if the underlying
+object is not of the child type, or a child of that.
+
+This does not however cause dynamic look-up. During function calls the
+underlying type is ignored, and the pointer type is used to type match the
+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.
+
+
+Syntax:
+
+"struct" name [ "tagged" [ parent-name ] ] "{" fields "}"
+
+The keywords can change (although they currently reflect the concept name
+closely). More formally, in terms of grammer this adds:
+
+struct-or-union-specifier
+	...
+	struct identifier tagged { struct-declaration-list }
+	struct identifier tagged parent-identifier { struct-declaration-list }
+
+"tagged" by itself create a tagged structure that is the root of a new tree.
+It has no parent tagged structure. If "tagged" is used with a parent than
+that is the parent of this node.
+
+Tagged structures have fields beyond the ones listed. Root tags have a type
+field added which give the type of the instance. Child tags prepend all of
+their parent's fields to their field list so they can be upcast.
+
+
+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.
+
+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.
+
+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.
+
+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.
+
+
+Traits:
+
+[is_]tagged[_struct](dtype T)
+True if the given T is a tagged struct of some kind. This promises that it has
+a type object, but nothing else.
+
+[is_]tagged_under(dtype parent, dtype child)
+True if child is a child type of parent. Requires that both are tagged structs
+and that child can upcast to parent.
+
+
+Functions:
+
+forall(dtype T | is_tagged(T), dtype U | is_tagged(U))
+T * dynamic_cast(U * value)
+The cast function, that safely converts the U* into a T*, returning null if
+the underlying object value points to is not a child type of T. A shorter name
+might be perfered. The runtime should be no more than linear with the depth
+of U in the inhiertance tree.
+
+bug#11 might require `bool dynamic_cast(T ** dst, U * src)` instead.