source: doc/proposals/tagged-struct.txt @ cdd1695

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.