Burton Radons wrote:
> Daniel Keep Wrote:
> 
>>
>> Burton Radons wrote:
>>> I'm writing a couple of modules for dealing with database values (well 
>>> really it's just storage of aggregates) in a native fashion from within D, 
>>> using D 2.023. I have a tuple called FieldTypes which contains the D-side 
>>> types. I'm trying to use it to implement opApply:
>>>
>>>     int opApply (int delegate (FieldTypes) func)
>>>
>>> Unfortunately, this fails because the compiler only accepts the field types 
>>> if they're references. But if I do this:
>>>
>>>     int opApply (int delegate (ref FieldTypes) each)
>>>
>>> It seems that the delegate takes a reference to one type, which is a value 
>>> tuple! For example it claims that, simplified, "function Table.opApply (int 
>>> delegate (ref (string, string)) each) does not match parameter types (int 
>>> delegate (ref string, ref string))".
>>>
>>> I've already implemented another opApply that takes a Line containing all 
>>> the fields, but I'd like to have the expanded form as well if possible. Is 
>>> it?
>> Yeah, I've run into this before.  I solved it at the time using CTFE and
>> string mixins:
>>
>> alias mixin(refDelegateFromTuple!(FieldTypes)) FieldTypesDg;
> 
> I couldn't quite figure out what you meant by this as DelegateFromTuple's not 
> part of Phobos from what I can tell, but I did get this going:

refDelegateFromTuple isn't in Phobos; so far as I'm aware, Phobos
doesn't contain any CTFE mixin functions.

>       pure string BuildArguments (string prefix, T...) ()
>       {
>               string text;
>               
>               foreach (type; T)
>               {
>                       if (text.length) text ~= ", ";
>                       text ~= prefix ~ " ";
>                       text ~= type.stringof;
>               }
>               
>               return text;
>       }
>       
>       alias TypeTuple! (int, float) FieldTypes;
>       mixin ("alias int delegate (" ~ BuildArguments! ("ref", FieldTypes) () 
> ~ ") FieldTypesDeg;");
> 
> Seems to work fine, I just don't know whether "stringof" is going to be 
> well-behaved here. Plus it's a little extra work for the compiler.

Looks fine to me; this is basically what I was suggesting, except I
would have made the function build the entire delegate type as a string
to clean up the calling code.

  -- Daniel

Reply via email to