container_appender (introduced by me) is a implementation-detail facility for flattening the container attribute types. It acts like a placeholder type to preserve the fact that "this attribute should be treated like a container, NOT a container of a container" concept; in pseudo-code: vector<int>{} >> vector<int>{} should be treated as vector<int>{}, i.e., NOT vector<vector<int>>{}.
The direct reason why I introduced container_appender is because I found that some internal code simply cannot be compiled due to complex attribute type handling involved in parse_sequence and parse_into_container. As a downside, it requires some overhead for move-appending the elements:
|
if constexpr (is_ttp_specialization_of_v<std::remove_const_t<Exposed>, container_appender>) { |
|
traits::append( |
|
exposed_attr.container, |
|
std::make_move_iterator(traits::begin(rule_attr)), |
|
std::make_move_iterator(traits::end(rule_attr)) |
|
); |
If we keep using container_appender, the above workaround theoretically cannot be eliminated because the rule parser's attribute cannot accept container_appender<Container> when Container is some user-provided type that is used by the rule which is intended to be instantiated in a different translation unit (cf. IRIS_X4_INSTANTIATE).
After #42 is merged, we should reinvestigate whether container_appender is still needed in the codebase.
container_appender(introduced by me) is a implementation-detail facility for flattening the container attribute types. It acts like a placeholder type to preserve the fact that "this attribute should be treated like a container, NOT a container of a container" concept; in pseudo-code:vector<int>{} >> vector<int>{}should be treated asvector<int>{}, i.e., NOTvector<vector<int>>{}.The direct reason why I introduced
container_appenderis because I found that some internal code simply cannot be compiled due to complex attribute type handling involved inparse_sequenceandparse_into_container. As a downside, it requires some overhead for move-appending the elements:x4/include/iris/x4/rule.hpp
Lines 451 to 456 in e811b03
If we keep using
container_appender, the above workaround theoretically cannot be eliminated because the rule parser's attribute cannot acceptcontainer_appender<Container>whenContaineris some user-provided type that is used by the rule which is intended to be instantiated in a different translation unit (cf.IRIS_X4_INSTANTIATE).After #42 is merged, we should reinvestigate whether
container_appenderis still needed in the codebase.