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

Last change on this file since cdd1695 was cdd1695, checked in by Andrew Beach <ajbeach@…>, 6 years ago

First draft of the tagged struct proposal.

  • Property mode set to 100644
File size: 3.4 KB
1Proposal to add simple inhieritance to the language.
3Tagged structures allow for dynamic casting between types in a hierarchy.
4Children (rather pointers to) can be up-cast to their parents, a safe
5conversion that may recive language level support or even be implicate.
6Parents can be down cast to their children, which might fail if the underlying
7object is not of the child type, or a child of that.
9This does not however cause dynamic look-up. During function calls the
10underlying type is ignored, and the pointer type is used to type match the
11function call.
13Tags cannot be used on unions. This is because the different sides interact
14with the casts rather badly. There is a similarity with tagged unions still.
15Tagged structures also carry data to identify which out of several
16possibilies the object actually is. Although the possibilies are dynamic in
17this case.
22"struct" name [ "tagged" [ parent-name ] ] "{" fields "}"
24The keywords can change (although they currently reflect the concept name
25closely). More formally, in terms of grammer this adds:
28        ...
29        struct identifier tagged { struct-declaration-list }
30        struct identifier tagged parent-identifier { struct-declaration-list }
32"tagged" by itself create a tagged structure that is the root of a new tree.
33It has no parent tagged structure. If "tagged" is used with a parent than
34that is the parent of this node.
36Tagged structures have fields beyond the ones listed. Root tags have a type
37field added which give the type of the instance. Child tags prepend all of
38their parent's fields to their field list so they can be upcast.
43Adding to the field list is a simple matter, should be doable during
44translation. The type field is just a pointer to a type object. With proper
45linking we can create a single unique instance of the type object for each
46declared tagged struct. The instance's address is used as an id for the type.
47It also holds data about the type, such as its parent's id/a pointer to the
48parent type object.
50If the type field is given a simple name, then the user can easily access the
51type object. This might be useful depending on what sort of data is in the
52type object, especially if the data can be added to by the user in some way.
53Ironically one way to accomplish that is to make the type objects tagged
54themselves, but that recursion might not have a base case.
56If the name is mangled and direct access to type objects is still wanted, then
57a function could be used to access the type object. Say get_type or get_tag
58instead of type or tag.
60If the data on the type object is set, than providing direct access may be
61unnessary. Instead the libraries or base code might be able to implement
62everything the data is for.
67[is_]tagged[_struct](dtype T)
68True if the given T is a tagged struct of some kind. This promises that it has
69a type object, but nothing else.
71[is_]tagged_under(dtype parent, dtype child)
72True if child is a child type of parent. Requires that both are tagged structs
73and that child can upcast to parent.
78forall(dtype T | is_tagged(T), dtype U | is_tagged(U))
79T * dynamic_cast(U * value)
80The cast function, that safely converts the U* into a T*, returning null if
81the underlying object value points to is not a child type of T. A shorter name
82might be perfered. The runtime should be no more than linear with the depth
83of U in the inhiertance tree.
85bug#11 might require `bool dynamic_cast(T ** dst, U * src)` instead.
Note: See TracBrowser for help on using the repository browser.