source: doc/proposals/tagged-struct.txt@ 579263a

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.


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.


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.

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.


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 "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.