On 09/19/13 16:40, Joseph Rushton Wakeling wrote:
>     alias EdgeProperties = Tuple!(double, "weight");
> 
>     alias VertexProperties = Tuple!(size_t, "colour", string, "name");
> 
> So then, you'd be able to extract the list of variable names and types at compile time and use them to create the underlying data structures required; and similarly you'd be able to create a set of public interfaces that gives you access to those members.
> 
> With that in mind, there are a number of potential issues that arise:
> 
>    (i) is there a compile-time constraint via which I can insist that every
>        member of the tuple must be named?
> 
>   (ii) is there an easy way to extract all the names of tuple members as an
>        array of strings?
> 
> Can anyone advise?

I'm not sure i understand your problem, but you could use structs. ie:

   struct VertexProperties {
      size_t color;
      string name;
   }

You can get the field names and types at CT and work with that.


artur

On Thursday, 19 September 2013 at 14:56:08 UTC, Artur Skawina wrote:
> I'm not sure i understand your problem, but you could use structs. ie:
>
>    struct VertexProperties {
>       size_t color;
>       string name;
>    }
>
> You can get the field names and types at CT and work with that.

+1 Why do you need to use tuples and manually force them into struct behavior instead of simply using structs?

On 19/09/13 16:55, Artur Skawina wrote:
> I'm not sure i understand your problem, but you could use structs. ie:
>
>     struct VertexProperties {
>        size_t color;
>        string name;
>     }
>
> You can get the field names and types at CT and work with that.

Yes, that's a good suggestion.  I guess I was thinking that it'd be easier to do something like

    auto g = Graph!(Tuple!(double, "weight"), Tuple!(size_t, "colour", string, "name"));

... than to force the user to define a struct up front and pass it as template parameter.

On 19/09/13 17:21, Dicebot wrote:
> +1 Why do you need to use tuples and manually force them into struct behavior
> instead of simply using structs?

I guess I was thinking it'd be more finnicky to do something like

   struct EdgeProperties { double weight; }

   struct VertexProperties { size_t colour; string name; }

   auto g = Graph!(EdgeProperties, VertexProperties);

... than to allow the user the flexibility of just knocking up a Tuple in the moment.  But now that I think about it, it's not actually more complicated really.

On 09/19/13 17:22, Joseph Rushton Wakeling wrote:
> On 19/09/13 16:55, Artur Skawina wrote:
>> I'm not sure i understand your problem, but you could use structs. ie:
>>
>>     struct VertexProperties {
>>        size_t color;
>>        string name;
>>     }
>>
>> You can get the field names and types at CT and work with that.
> 
> Yes, that's a good suggestion.  I guess I was thinking that it'd be easier to do something like
> 
>     auto g = Graph!(Tuple!(double, "weight"), Tuple!(size_t, "colour", string, "name"));
> 
> ... than to force the user to define a struct up front and pass it as template parameter.

Yeah, support for anonymous structs as template parms would be useful;

    auto g = Graph!(struct { double weight; size_t color; string name });

But that's not currently possible.


You can do something like:

    auto g = Graph!q{ double weight; size_t color; string name; };

then, inside the Graph template:

   // template Graph(string F, ...) {
      struct S { mixin (F); }
      // ...look at fields of 'S'...


(This will work if you only need builtin types and/or custom ones already available in the Graph template)

artur