Re: [PFR][review] Andrzej's review

From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2020-10-06 19:50:54

wt., 6 paź 2020 o 19:53 Antony Polukhin <antoshkka_at_[hidden]> napisał(a):

> вт, 6 окт. 2020 г. в 12:22, Andrzej Krzemienski via Boost
> <boost_at_[hidden]>:
> >
> > Hi Everyone,
> > This is my partial review of PFR library.
> <...>
>
> Many thanks!
>
> As the reviews go I'm getting an impression that the library needs to
> lose weight:
> * drop the flat reflection
> * drop the global operators
> * drop the macro for declaring operators for type
>
> This will make the library 2/3 smaller and simpler to understand,
> along with solving the problems of macro customizations and accidental
> flat_* usages.
>

I, on the other hand, during the review started to appreciate the "flat"
part. I realized I had a good use case for it.
At times, I found myself in the situation of having a number of aggregate
types with the common set of members:

```
struct Person {
  std::string firstName;
  std::string lastName;
  int age;
};

struct Employee {
  std::string firstName;
  std::string lastName;
  int age;
  double salary;
};

struct Prisoner {
  std::string firstName;
  std::string lastName;
  int age;
  int cellNumber;
};
```
I would immediately rewrite it to:

```
struct Person {
  std::string firstName;
  std::string lastName;
  int age;
};

struct Employee : Person {
  double salary;
};

struct Prisoner : Person {
  int cellNumber;
};
```
This (a) avoids duplication, and (b) I have the slicing do exactly what I
need: convert an Employee to a Person. Now, I am disappointed with what
C++17 did to aggregate initialization. My natural expectation would be that:

```
Employee e {"Bilbo", "Baggins", 111, 1000.00};
```
Flattens the class hierarchy and initializes each of the four members.
Apparently , the C++ committee has a different vision for it. But I have
noticed that if I changed derivation into aggregation (as I indicated
earlier), the "flat" part of FPR would do exactly what I needed.

I wonder what is your *primary* motivation for removing it:
A. Because it is not implementable in many cases?
B. Because there is not enough motivation for it, and people don't
understand what it is for?
C. Because it can be accidentally confused with the "precise" version?

If it is (A), then I guess you are right. If any other then maybe leaving
it in would be a better alternative.

Regards,
&rzej;