Index: doc/proposals/virtual.txt =================================================================== --- doc/proposals/virtual.txt (revision ec71a50975a9d7697d5de0e27072837d6203d86d) +++ doc/proposals/virtual.txt (revision 50fb7df0b466a82323d69b26be20ba183ac46391) @@ -87,8 +87,8 @@ first polymorphic parameter). -Once a function in a trait has been marked as virtual it defines a new -function that takes in that trait's reference and then dynamically calls the -underlying type implementation. Hence a trait reference becomes a kind of -abstract type, cannot be directly instantiated but can still be used. +Instances of a trait are created by wrapping an existing instance of a type +that implements that trait. This wrapper includes all the function pointers +and other values required to preform the dynamic look-up. These are chosen by +the normal look-up rules at the point of abstraction. One of the limitations of this design is that it does not support double @@ -98,4 +98,8 @@ is also restricted, initially forbidden, see extension. +Ownership of the underlying structure is also a bit of a trick. Considering +the use cases for trait object, it is probably best to have the underlying +object be heap allocated and owned by the trait object. + Extension: Multi-parameter Virtual Traits: @@ -157,4 +161,20 @@ context, for instance if the cast occurs on the right hand side of an assignment. + +Function look-up follows the same rules as relaxed (behavioural) inheritance. +Traits can be upcast and down cast without losing information unless the +trait is cast down to a structure. Here there are two options. + + Abstraction Time Binding: The more efficient and consistant with other parts +of CFA. Only the trait types use dynamic look-up, if converveted back into a +structure the normal static look-up rules find the function at compile time. +Casting down to a structure type can then result in the loss of a set of +bindings. + Construction Time Binding: For more consistant handling of the virtual +structs, they are always considered wrapped. Functions are bound to the +instance the moment it is constructed and remain unchanged throughout its +lifetime, so down casting does not lose information. + +(We will have to decide between one of these two.) Extension: Multiple Parents @@ -205,21 +225,33 @@ We have so far been silent on how the vtable is created, stored and accessed. - -Creation happens at compile time. Function pointers are found by using the -same best match rules as elsewhere (additional rules for defaults from the -parent may or may not be required). For strict virtual this must happen at the -global scope and forbidding static functions, to ensure that a single unique -vtable is created. Similarly, there may have to be stricter matching rules -for the functions that go into the vtable, possibly requiring an exact match. -Relaxed virtual could relax both restrictions, if we allow different vtable -at different conversion (struct to trait reference) sites. If it is allowed -local functions being bound to a vtable could cause issues when they go out -of scope, however this should follow the lifetime rules most C programs -already follow implicitly. - -Most vtables should be stored statically, the only exception being some of -the relaxed vtables that could have local function pointers. These may be able -to be stack allocated. All vtables should be immutable and require no manual -cleanup. +The vtables for the two types might be handled slightly differently and then +there is also the hierarchy data for virtual casts. + +The hierarchy data is simple conceptually. A single (exactly one copy) pointer +for each type can act as the identity for it. The value of the pointer is +its parent type, with the root pointer being NULL. Additional meta-data +can accompany the parent pointer, such as a string name or the vtable fields. + +They types of each vtable can be constructed from the definitions of the +traits (or internal nodes). The stand alone/base vtable is the same for both +kinds of inheritance. It may be argumented differently however (include parent +/this pointer in hierachal inheritance). + +Creation of the actual vtable is tricky. For classical single implementation +semantics we would assemble the functions and create one vtable at compile +time. However, not only does this not give CFA-like behaviour, it is +impossible generally because types can satify assertions in different ways at +different times and stop satifying them. A special set of harder rules could +be used, instead we have decided to try creating multiple vtables for each +type. The different vtables will all implement the same type but not always +in the same way. + +Storage has some issues from creation. If the contents of every vtable could +be determained at compile time they could all be created and stored +statically. However since thunks can be constructed on the stack and become +the best match, that isn't always possible. Those will have to be stored in +dynamic memory. Which means that all vtables must be stored dynamically or +there must be a way to determain which ones to free when the trait object is +destroyed. Access has two main options: