I think Abel needs the value encoded in the type
Ok. Now I get it. That was the critical piece of information I did not get from the previous communications. Thanks for clearing that up. I think that the term "compile-time string" led to the confusion, because there is already a pretty good tradition of compile-time string construction and manipulation. In the sense that it pre-computes or pre-parses strings during compilation. The idea of computing types out of compile-time strings is a different problem altogether. And I would not call this "compile-time strings", I would call them "meta-programming strings", because that's what they are, strings used to construct types (i.e., meta-programming). The terms used completely threw me off there.
I can't see a straightforward way to pass such constexpr string as a template parameter and do something reasonable with it internally.
Yeah, sorry, my bad. I completely missed that point somehow. I guess the "metafunction" should have been a hint, but I guess it must be getting late. You're right, the barrier to cross from constexpr to template parameters is pretty much impenetrable as far as strings are concerned (btw, you can easily use a constexpr string to generate a unique hash that can be used to construct a type that is unique to the original string, but I guess that's not quite what you are looking for). So yeah, you're right, you cannot do that with compile-time strings.
My intention was to implement a compile-time Spirit that operates on CT string and returns different types depending on the input, so my usage is a bit different.
Ok, I see, you want to remain purely TMP the whole way, and the end-goal of your expressions are types, not strings. (BTW, if your goal is compile-time string parsing, then you ought to be using constexpr strings, not TMP strings, because as much overhead as there is when using constexpr for this kind of work, I would imagine the overhead of using TMP for this would be astronomical, intractable) In that perspective, I can totally see how your MACRO might make sense, if it was legal. The trick really is to circumvent the standard rules that essentially make it impossible to map a string literal into a template parameter pack of chars. I think that with your use of the lambda expression, you tried to cheat your way out of those rules, but there is a specific rule for that loophole, $5.1.2/2: "A lambda expression shall not appear in an unevaluated operand" This means that you cannot try to smuggle a string literal out of an unevaluated lambda in order to get it into a type. And the rationale for this rule is specifically aimed at avoiding opening the can of worms that it would be if people were allowed to do meta-programming from lambda's, because you could hide all sorts of monstrous things in a lambda and then pull them out into templates. That pretty much closes off your proposed avenue, doesn't it? If you got this to work, I would have to imagine it is due to working with a non-compliant compiler. I tried your code with both clang 3.5 and GCC 4.8.2, and they both reject it on the grounds of the rule that I just stated. You'll have to find another way to do this. It is a tough problem. And when it comes to working with string literals, I'm afraid the pre-processor is pretty much all you have, as Abel evidently realized when creating the MPLLIBS_STRING macro. I personally find this problem very frustrating because we all know that all compilers could do a lot more work with strings at compile-time, either as constexpr or as template parameters. And we wouldn't have to resort to such ridiculous and inefficient solutions as macro expansions or template instantiations with packs of chars. Sorry again for my initial misunderstanding of your aim with the code you showed. Cheers, Mikael Persson