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 implicit. 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. 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. Alternate names include virtual structure and abstract structure. Syntax: "struct" name [ "tagged" [ parent-name ] ] "{" fields "}" The keywords can change (although they currently reflect the concept name closely). More formally, in terms of grammar 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. 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 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. 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. 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: [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. 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 "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. 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. Type Objects Fields (Extention): 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 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. 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);