Changeset 1a42132

Timestamp:

Jun 16, 2017, 1:44:08 PM (7 years ago)

Author:

Andrew Beach <ajbeach@…>

Branches:

ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc

Children:

f522618

Parents:

f13ee31

Message:

Added Aaron's comments to the tagged-struct proposal.

File:

• doc/proposals/tagged-struct.txt (modified) (3 diffs)

doc/proposals/tagged-struct.txt

@@ -11 +11 @@
 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.
+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.
 
 
@@ -48 +46 @@
 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.
+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.
 
-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.
+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.
 
-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.
+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.
 
 
@@ -84 +81 @@
 
 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.