Dean Michael Berris wrote:
I've also tried going with fusion::at_c in my initial attempt to get the correct result type, only that I run into problems with const correctness. I'll try my hand at it some other time though.
What's the problem? I doubt it's const correctness. I'm guessing it's value/reference confusion. Here's a tip: /value_at/ returns the actual type while /at/ returns a reference or value depending on the sequence. For example: tuple<int&, int> t(i, 123); What should /at/ and /value_at/ return? Now, how about this: mpl::vector_c<123, 456> is; What should /at/ and /value_at/ return? /at/ always tries to return an L-value whenever possible to allow mutation (note: "whenever possible" -- it's not always possible). /at/ also tries to return a const-reference, again whenever possible, to avoid copies. It is naive to simply strip the reference to get the value because there's no way to know the actual value if the element is a reference to begin with (first example). That's where value_at helps. This *is* very tricky and I suggest you don't reinvent the wheel. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net