[PFR] Some questions

From: Gavin Lambert (boost_at_[hidden])
Date: 2020-10-05 00:29:54

This is not (yet?) a review, although I guess this could be counted as a 
partial review towards the current state of the docs; but after reading 
them I have several questions.

1. Why is the term "reflection" used at all?  As far as I am aware, this 
is primarily used to refer to accessing member names from the structure, 
which is not something that this library provides at all, so at best 
this seems highly misleading.  The original "magic get" name seems more 
appropriate since it is primarily about extending tuple-get to basic 
structures without boilerplate macros.

2. An up-front clarification on the limitations of supported structures 
would be nice.  "Aggregate initialisable" is not a concept that everyone 
is familiar with.

3. What is the motivation for "flat" reflection to exist, at all?  I 
can't find any explanation of why one might want to do it; other than 
completely disregarding type safety, which seems like a bad thing.  (I 
assume there is some reason that I'm not aware of, but that's why an 
explanation would be nice.)

4. Flat reflection is stated to be non-portable, raising further 
questions as to why it exists at all.

5. Many of the intro pages talk about "disabling loophole" with no 
explanation of what that is.  The configuration macros page finally 
presents a link that doesn't really explain anything anyway, other than 
suggesting it is a Dark Magic that was intended to be banned but nobody 
had gotten around to it yet.

6. Speaking of the configuration macros page, it doesn't indicate what 
values are the defaults, other than it "auto-detects your compiler".  I 
assume from the surrounding text that it would prefer to use C++17 and 
would use "loophole" (whatever that is) otherwise, but it would be good 
to make that (or whatever it actually does instead) explicit.

Granted #3 can't get you into *too* much trouble with the limitation on 
only supporting aggregate-initialised types... but on the other hand, 
type hierarchies are still significant for aggregates (it can be 
important to distinguish a "handle" from a plain int, or a Boost.Units 
value from another with different unit).  And it feels like you're doing 
C++ wrong if you're using aggregate types much; they're only a little 
better than PODs.

(In all existing codebases I use, there are almost no aggregate types, 
although there are a few almost-aggregates that have simple initialising 
constructors, for example, or make member fields private and use a 
get-set method pattern "just in case".  I imagine this is likely to be 
true of most real-world codebases.)

Having said that, I can see some value in aggregate types as DTOs (for 
database/json/etc translation) and for reducing usage of std::pair and 
std::tuple, which is a good thing, though only if used in limited scope. 
  But that usage doesn't explain "flat" either; the type hierarchy still 
should be important.

Precise reflection, on the other hand, seems more potentially useful, 
save for the unfortunate -- though understandable -- limitation on only 
aggregates.  Having said that, I've personally never found a use-case 
for a tuple-like get interface for anything, so perhaps I'm just not the 
target audience for this library.

(I also have a strong dislike for aggregate initialisation being 
order-based in the first place; I would have preferred something like 
C99's named initialisation.  C++20 is adding something that they're 
calling that, but is utterly useless and crippled instead of doing it 
properly.)