Allow string literals and reflection in/of record dimension

[bernhardmgruber]

Allows the following:

    using RecordDim = llama::Record<
        llama::NamedField<"x", int>, // NEW: NamedField with string literal
        llama::NamedField<"y", int>,
        llama::NamedField<"pos", Vec2F>,
        llama::Field<tag::Vel, llama::Record<llama::Field<tag::X, float>, llama::NamedField<"y", float>>>>;

    using namespace llama::literals;

    auto view = llama::allocView(llama::mapping::AoS{llama::ArrayExtents{1}, RecordDim{}});
    view(0)("x"_Name) = 1; // NEW: access with string literal (using literal operator _Name)
    view(0)("y"_Name) = 2;
    view(0)("pos"_Name, tag::X{}) = 3;
    view(0)("pos"_Name, tag::Y{}) = 4;
    view(0)(tag::Vel{}, tag::X{}) = 5;

Any better suggestions over NamedField and _Name?

And:

    struct MyVel
    {
        int x;
        int y;
    };
    BOOST_DESCRIBE_STRUCT(MyVel, (), (x, y));

    struct MyStruct
    {
        int a;
        int b;
        MyVel pos;
    };
    BOOST_DESCRIBE_STRUCT(MyStruct, (), (a, b, pos));

    using RecordDim = llama::ReflectToRecordDim<MyStruct>; // NEW
    auto view = llama::allocView(llama::mapping::AoS{llama::ArrayExtents{1}, RecordDim{}});

    using namespace llama::literals;

    view(0)("a"_Name) = 1;
    view(0)("b"_Name) = 2;
    view(0)("pos"_Name, "x"_Name) = 3;
    view(0)("pos"_Name, "y"_Name) = 4;

[codecov]

Codecov Report

Merging #737 (dc3a1b1) into develop (9d0d3a7) will decrease coverage by 0.03%.
The diff coverage is 93.33%.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop     #737      +/-   ##
===========================================
- Coverage    98.81%   98.79%   -0.03%     
===========================================
  Files           75       75              
  Lines         7167     7197      +30     
===========================================
+ Hits          7082     7110      +28     
- Misses          85       87       +2     

[SimeonEhrig]

Why do you need to use string literals explicit for function arguments, but template arguments are implicit working.

My suggestion, for the literal: llfield or LLfield -> short for llama field.

[bernhardmgruber]

Why do you need to use string literals explicit for function arguments, but template arguments are implicit working.

In llama::NamedField<"x", int> I have the value "x" available as a constant expression and can meta-program on it. Specifically, I need to turn the string literal into a type. In view(0)("x") I have the value "x" available only at runtime, so I cannot meta-program. This would require constexpr function parameters, which were proposed but never accepted into C++. My workaround is to use a literal operator which turns the string literal into a type carrying the string's value.

[SimeonEhrig]

Why do you need to use string literals explicit for function arguments, but template arguments are implicit working.

In llama::NamedField<"x", int> I have the value "x" available as a constant expression and can meta-program on it. Specifically, I need to turn the string literal into a type. In view(0)("x") I have the value "x" available only at runtime, so I cannot meta-program. This would require constexpr function parameters, which were proposed but never accepted into C++. My workaround is to use a literal operator which turns the string literal into a type carrying the string's value.

Thanks for clarification.

[psychocoderHPC]

I like the idea of using string types to name the components. I suggest instead of _Name, _tag.

I'm not sure if the example with BOOST suggests making llama depending on a boost feature but I would be happy if using BOOST_DESCRIBE_STRUCT will be only an optional way and the boost dependency is in this case only optional too.

[bernhardmgruber]

I like the idea of using string types to name the components. I suggest instead of _Name, _tag.

How would you call NamedField then for consistency?

I'm not sure if the example with BOOST suggests making llama depending on a boost feature but I would be happy if using BOOST_DESCRIBE_STRUCT will be only an optional way and the boost dependency is in this case only optional too.

The new feature is entirely optional. It needs a recent enough Boost version.