On Friday, 6 June 2014 at 22:27:38 UTC, bearophile wrote:
John:
I can iterate over the struct elements with the traits
FieldTypeTuple!foo,
In such iteration you are using a static foreach. Types are
compile-time constructs in D. If you need run-time entities you
need to get their typeinfo.
I don't want to do that lookup at runtime though. Clearly my
intent is to rewrite this foreach zip expression as:
auto s = test.split(",");
writeln(to!int(s[0]));
writeln(to!float(s[1]));
or maybe:
auto s = test.split(",");
writeln(to!int(s.front));
s.popFront();
writeln(to!float(s.front));
But I don't want to actually hand write that each time.
I can iterate over the the string that represents the elements
I want to shove in the struct,
This is a "dynamic" (regular) foreach.
Yes.
but when I try to loop over *both* of these at the same time
with zip(...) I get an error.
zip only works on run time values. So you can't zip a built-in
typetuple of types with a range of values.
Conceptually that is what I want to do though. I want to pair the
type with the string that I'm going to convert.
I'm not sure if it's actually a range? I assumed it would be a
range of some kind,
It's not a range. FieldTypeTuple returns a built-in typetuple
that in this case is really a built-in of types, that are
purely compile-time entities.
I get that.
and each of the elements would have a supertype of something
like 'type' since that's what they are.
They are types (and they aren't other things like
uninstantiated templates that in D are another kind), but not
even in our dreams there is a supertype for them :-)
It could infer that now you have two ranges, one of 'type' and
one of 'string'.
Nope.
If I'm able to foreach over two things, shouldn't I be able to
foreach over the paired ranges with zip? It seems so simple...
If you turn the built-in typetuple of types into an array or
lazy range of typeinfo, then you can zip them. But I don't
think this is a good idea. It's better to forget the zipping
and use a static foreach on the types, using also an index, and
use such index to access the second array of run time values.
I had already considered a workaround like that, but it's just
that. A workaround. You already do unrolling for templates, this
isn't much different (at least conceptually).
You could basically do exactly what you're describing in the
library, no? Have zip loop over all the static/compile time
fields (assuming you can separate them in the template from the
runtime ranges), and index into (or pop range) the runtime ranges
with length checks. The compiler would unroll the compile time
ranges (or whatever you want to call them) creating essentially
exactly what you've described, the other poster mentioned, and
precisely what I put above.
Is that not possible?
Bye,
bearophile
