TypeInfoEx and Variant: suggestions?

[Andrei Alexandrescu]

dsimcha wrote:
> == Quote from Christopher Wright (dhasenan at gmail.com)'s article
>> Hi all,
>> I finally found some time to work on TypeInfoEx. It's usable, in that
>> you can view information about a type; but you can't do anything with
>> that information. One large barrier is the lack of a usable Variant type.
>> To invoke a function on an object or struct, you need to pass it as
>> either Object or void* or Variant.
>> If you invoke a function, you want to pass in an array of Variant for
>> the arguments. You want to get the return type as a Variant.
>> If you get a field, you want to get it as a Variant.
>> You could use templates instead, but that's not usable in many
>> situations, so I won't have that as the only option.
>> Andrei's std.variant has an interesting design, but it has two flaws
>> that render it unusable:
>>   - It cannot be used with structs of arbitrary size. It's parameterized
>> on size, but no size will always be sufficient; and due to its
>> allocation scheme, choosing to support (for instance) 1KB structs will
>> force a bool to take 1KB.
>>   - It cannot be created with RTTI; it requires compile-time type
>> information.
>> So, my options are:
>>   - Write my own Variant supporting the necessary operations. This makes
>> things annoying for anyone wanting to use my code with Phobos, since now
>> there are two Variant structs running around.
>>   - Use std.boxer, which is deprecated.
>>   - Pass around an opaque Pair!(TypeInfo, void*).
>> Any suggestions? I've written such a Variant for D1 and Tango, but I
>> relish neither the idea of supporting both with the same class, nor code
>> duplication.
> 
> Andrei has said that he would like to fix std.variant to support arbitrary sized
> stuff, but just doesn't have time right now.  If you are able and willing, submit
> a patch.  If it's decent, it will probably be accepted.  If you don't have time or
> don't want to, someone who does should submit one since this seems to be something
> a lot of people want.  I've looked at doing this before, and I'd be willing to
> step up and submit a patch after some of my coursework dies down and I have more
> free time (fairly soon), if noone else gets around to it before then.

It would be great if somebody could find the time to implement the pesky 
arbitrarily-sized structs for Variant.

I don't have much time to add to this interesting discussion, but let me 
make a few quick points. First off, I'm very happy that discriminated 
unions are receiving increased interest from the community. I think they 
are an interesting abstraction mechanism with cool applications in 
dynamic code.

Second, I have hacked discriminated unions for years and wrote a fairly 
influential paper on them as far back as 2001 (which has inspired many 
others, including Boost's), and some more articles later on. I can say 
that std.variant is the best implementation of a discriminated I've 
seen, by a mile. std.variant is truly general (at no point in its design 
or implementation appears a list of supported types), well positioned 
for working with full introspection when that will become available, 
tight in memory usage, and extremely fast because it uses only one 
indirect call for dispatching. The latter point is very important in 
heavy-duty usage; hash-based dispatch sounds and looks good on paper, 
until you need to invoke it in a tight loop. Then you'd start trying to 
avoid it, which undermines motivation for using variants.

Lack of construction from RTTI is not a major limitation and can be 
obviated. RTTI objects cannot be forged, so they were created from some 
objects that did have static type information available. This suggests 
that code can be shuffled such that Variant construction is done at that 
point, instead of getting the RTTI alone (and losing static type 
information) and attempting to construct the Variant later.


Andrei