5

Combining if constexpr with some <type_traits> entities, in C++17, I'm able to inspect types at compile time. Can these techniques be considered static reflection? Or is it just type inspection? Example:

if constexpr (std::is_same_v<T, U>) statement

Does the reflection concept apply only to runtime? Is right to call it static reflection?

user207421
  • 305,947
  • 44
  • 307
  • 483
João Paulo
  • 6,300
  • 4
  • 51
  • 80
  • `applies only to runtime`, do you mean `compile time`? – ph3rin Oct 01 '19 at 03:08
  • No, I really meant runtime. The reflection tag description, for instance, says it's for runtime. I also would like to know if the reflection terminology also applies to compile time. – João Paulo Oct 01 '19 at 03:26
  • 2
    There is such a thing as compile-time or static reflection, but the C++17 capabilities fall short. For example, there's no way to iterate all the members of a given type, you can only fetch information for a type member you know in advance. – Ben Voigt Oct 01 '19 at 03:35
  • Whether technique A can be considered to fall in category B is largely opinion-based. There isn't really an objective judging standard. – L. F. Oct 01 '19 at 04:03

2 Answers2

11

Could is_same be considered a form of static reflection? It is in fact static, a compile-time detectable property of a type. And you can in fact write code that will execute based on introspecting this property. So technically, it is perfectly valid to call it "reflection".

But if you're going to be useful with words, if you want to effectively use words to communicate, then you have to recognize that dictionary definitions aren't exactly useful. This is because people have different dictionaries, different expectations of what words mean. And words can change their meaning or have special meaning in different contexts. So if you're going to effectively communicate with people, you have to use words that will actually convey the meaning that you intend to communicate.

In particular, the words "static reflection" in the context of C++ typically refer to functionality related to this proposal (PDF) (cleverly named "Static Reflection") and its many, many revisions. Specifically, if you make the claim that C++ has "static reflection" as some kind of language feature, then to many C++ users, you are making the claim that users can do things like enumerate properties about a class (like the member subobjects of a type) and iterate over them, performing some action on each such property.

After all, that is what you can do in other languages that offer reflection as a first-class feature. "Reflection" is not just being able to ask if a given type is a particular type or if a given type satisfies a basic property. Reflection is about being able to introspect pretty much every facet of interest on a type.

That's the expectation that the term "static reflection" gives many C++ programmers. When C++ programmers talk about wanting "static reflection", that is what they're saying that they want.

So while you could technically claim that C++ already has "static reflection", it is not useful to make such a claim.

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
3

I would say that yes, the basic idea that reflection can be done at compile time (giving static reflection) is entirely reasonable. In fact, there have been a number of papers about static reflection in C++ for a while now. For one obvious example, consider N3996: Static Reflection.

In fact, the C++ Committee has an official Study Group (SG 7), which now covers compile-time programming in general, but was originally dedicated to static reflection.

Now as to whether static if with some type traits qualifies as static reflection, I'd say the answer is "yes", but with some pretty heavy qualifications, or at least limitations. For example, static if with type traits probably isn't sufficient to implement any of the motivating examples shown in the paper linked above.

Nonetheless, it does allow some minimal degree of reflection, and it's done at compile time, so it clearly is static reflection.

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111