Closed bernhardmgruber closed 1 year ago
Merging #737 (dc3a1b1) into develop (9d0d3a7) will decrease coverage by
0.03%
. The diff coverage is93.33%
.
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.
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.
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. Inview(0)("x")
I have the value"x"
available only at runtime, so I cannot meta-program. This would requireconstexpr
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.
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.
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.
Allows the following:
Any better suggestions over
NamedField
and_Name
?And: