Variants and pattern matching implementation

Reiner Pope reiner at none.com
Sun May 6 23:31:14 PDT 2007


Reiner Pope wrote:
> Comments would be much appreciated.

I'll start them off myself <g>.

There are two main things in the current result that I'm not satisfied with:

1. The error messages don't propagate correctly, so that the line number 
given is the line in variant.d, although the error is actually on the 
caller's side. Of course, printing an error backtrace, although it 
would work here, but may just be an annoyance in other code.


2. Exposure doesn't work correctly, and I don't know what to do.
For instance, I don't currently know how to declare a type in some 
module, and use it in Variant!(). The problem is that, to create the 
opAssign's, I currently *need* to use string mixins (because of a 
template mixin annoyance detailed below), and the string mixin appears 
to be evaluated in a scope which is unaware of my declared type.

Similarly, I need to expose Variant's internals, although that makes 
more sense, since I access them at the call site.


Two other annoyances are:

1. Funny template mixin behaviour.
After using a lot of text mixins, I tried to make my code cleaner by 
using other language features (I turned one into a simple tuple, and I 
tried to turn the opAssign declarations into a template mixin). To make 
multiple opAssigns, I used the following template:

template makeOpAssigns(ulong index, T...)
{
     static if (index < T.length)
     {
         pragma(msg, itoa(index));
         typeof(*this) opAssign(T[index] value)
         {
             _variant_data[index] = value;
             _variant_type = index;
             return *this;
         }
         mixin makeOpAssigns!(index + 1, T);
     }
}

but it appears that the T[index] in the function prototype doesn't use 
the 'index' template parameter, but actually uses 'index' from an 
external scope. At least, that's what it seems, although this surprises me.

2. Lack of types for templates parameters.
It would really be nice to express what *kind* of template parameters 
you want in more detail (this specifically refers to alias parameters, 
and their tuple counterparts). I know of at least three specific times 
in writing the variant that I forgot/misunderstood the type the 
parameter was -- I can't help feeling that some kind of Concepts idea 
for template parameters would be nice.


But other than that, writing it was great -- it is quite amazing how 
much you can do with mixin/CTFE/static if.

Cheers,

Reiner



More information about the Digitalmars-d mailing list