Support for C-style arrays.

[hazby2002]

Currently C-style arrays are not supported. The following example will trigger compile errors:

#include <iostream>

#include "rfl.hpp"
#include "rfl/json.hpp"

struct A {
 int a[3];
};

int main() {
  A a = {1, 2, 3};

  std::cout << rfl::json::write(a) << "\n";  // Expect: {"a":[1,2,3]}
}

The reason is that rfl::internal::has_n_fields gives wrong results for struct A.

C-style arrays are not allowed to be initialized by copy or move. In such cases, Any{} will be converted as the element type of the C-style array due to brace elision of aggregate initialization (just like the example above, a can be initialized with single pair of braces). As a result, has_n_fields<A, 3> is true.

This can be solved by a little more work when calculating the fields of aggregate types. I've written a demo with randomly generated tests to validate my thoughts.

[liuzicheng1987]

@hazby2002 Cool stuff. Since you already have a solution, do you want to simply open a PR or do you want me to integrate your Godbolt solution into the code?

[hazby2002]

@liuzicheng1987 I will try to open a PR (I've never done that before). To support C-style arrays, I think there will be more work to do other than my Godbolt demo. Anyway, I am going to integrate my solution first.

[hazby2002]

It seems to be difficult to support C-style arrays :(

C-style arrays do not allow copy or move and functions cannot return an array. As a consequence, Result<T[n]> causes compile errors, and many other template classes are the same. Much use of std::decay (which makes the code treat c-arrays as pointers) also makes it hard to integrate c arrays . I have many thoughts to process an aggregate with nested c-arrays but things become difficult in a such big codebase.

Maybe further discussions are required on this problem.

[ChemiCalChems]

We are using C++20... Maybe we should look into supporting std::span which models contiguous memory, thus inherently modelling arrays.

[liuzicheng1987]

OK, I will think about this as well. I was busy with the Writer stuff, but I will take a look at this as well.

[liuzicheng1987]

@hazby2002 , do you feel you are stuck? Maybe I could open a feature branch and you could merge your stuff in there? Then I could take it from there.

[hazby2002]

@liuzicheng1987 Write operations have been implemented and I think #40 is complete enough to be merged. ~I'm stuck on the implementation of read operations, therefore it's better to merge #40 first, no matter to a feature branch or others.~

I have added a not that beautiful implementation of read operations.

[liuzicheng1987]

Resolved with the merge of your PR.