Changes in / [f6cc2096:70284830]

File:

• doc/proposals/virtual.txt (modified) (3 diffs)

doc/proposals/virtual.txt

@@ -147 +147 @@
 
 This gives us an important extra feature, runtime checking of the parent-child
-relationship with virtual cast, where a pointer (and maybe a reference) to
-a virtual type can be cast to another virtual cast. However the cast is
-dynamicly check and only occurs if the underlying type is a child of the type
-being cast to. Otherwise null is returned.
-
-(virtual TYPE)EXPR
-
-As an extention, the TYPE may be ommitted if it can be determained from
-context, for instance if the cast occurs on the right hand side of an
-assignment.
+relationship with a C++ dynamic_cast like operation. Allowing checked
+conversions from trait references to more particular references, which works
+if the underlying type is, or is a child of, the new trait type.
 
 Extension: Multiple Parents
@@ -258 +251 @@
 autogenerated and often unique.
 
-It may be worth looking into a way to force the vtable pointer to be in a
-particular location, which would save the storage to store the offset and
-maybe the offset operation itself (offset = 0). However it may not be worth
-introducing a new language feature for.
-As of writing, exceptions actually use this system.
-
 
 Keyword Usage:
@@ -289 +276 @@
 Calling free on a trait reference will free the memory for the object. It will
 leave the vtables alone, as those are (always?) statically allocated.
-
-
-Special Traits:
-
-trait is_virtual_parent(dtype parent, dtype child) { ... };
-
-There are others but I believe this one to be the most important. The trait
-holds if the parent type is a strict virtual ancestor (any number of levels)
-of child. It will have to exist at least internally to check for upcasts and
-it can also be used to optimize virtual casts into upcasts. Or a null value or
-error if the cast would never succeed. Exporting it to a special trait allows
-users to express that requirement in their own polymorphic code.
-
-
-Implementation:
-
-Before we can generate any of the nessasary code, the compiler has to get some
-additional information about the code that it currently does not collect.
-
-First it should establish all child->parent links so that it may travel up the
-hierarchy to grab the nessasary information, and create the actual parent
-pointers in the strict virtual tables. It should also maintain the connections
-between the virtual type (structure or trait), the vtable type and the vtable
-instance (or default instance for relaxed virtual if multiple are allowed). To
-this end a sub-node should be created with the nessasary pointers. Traits and
-structs with virtual can create an instance and store all the nessasary data.
-
-With the hierarchy in place it can generate the vtable type for each type,
-it will generally have a function pointer field for each type assertion in
-some consistant order. Strict virtual will also have a pointer to the parent's
-vtable and intrusive vtables will also have the offset to recover the original
-pointer. Sized types will also carry the size.
-
-Wheither the vtable is intrusive or not should also be save so that the trait
-object/reference/pointer knows if it has to store 1 or 2 pointers. A wrapper
-function will have to be generated for each type assertion so that they may
-be called on the trait type, these can probably be inlined.
-
-The virtual parameter will also have to be marked (implicately or explicately)
-until code generation so that the wrapper functions know where to go to get
-the vtable for the function look up. That could probably be added as a
-storageclass, although one that is only valid on type assertions.
-
-The generated vtable will than have to have a vtable instance created and
-filled with all the approprate values. Stricter matching may have to be used
-to ensure that the functions used are stable. It will also have to use
-".gnu.linkonce" or equilant to ensure only one copy exists in the final code
-base.