Unexpected results when setting a parameter value with a string returned from a lambda

[spchamp]

After storing a string value to an argument pack for a given parameter keyword, when the string value is provided via std::invoke of a lambda expression, then the string retrieved for that same keyword may represent an unexpected value.

There's a minimal example of the issue, available at the Compiler Explorer.

The parameter value is being set with the following function:

template <typename Tag, typename Func, typename Args>
  requires (!detail::argument_pack_contains<Args, param::keyword<Tag>>::value)
inline auto ensure_param_default(Args const& args, param::keyword<Tag> const& kw,
                                 Func&& func) {
  return param::compose((kw = std::invoke(func, args)), args);
}

When this is called like as follows, the resulting string value may have a size far exceeding 3:

BOOST_PARAMETER_NAME((_arg1, tags) test_arg1)
BOOST_PARAMETER_NAME((_arg2, tags) test_arg2)
 
// [...]

int main() {
  auto const args_in = (_arg2 = 31213);

  auto const args_out =
        ensure_param_default(args_in, _arg1, [](auto const&) -> std::string {
          return "ABC";
        });

   // [...]

  std::string const& s_out = args_out[_arg1];

  // [...]
}

With the example at the Compiler Explorer, when this is compiled locally, I'm seeing results such as the following. The mangled string is varying in each call.

-- failed : string test
s_out.size() := 140722429578688
s_out.data() := �9
-- passed : int test

The Compiler Explorer may not display the unexpected character data, in this case.

I'd discovered this when trying to produce a function that would return an argument pack, after providing any system-specified default values for certain keywords when not provided in the user args. This was for a purpose of applying the resulting argument pack, when initializing a Boost.Log console frontend. I'm certain that there may be other ways to approach this, using Boost.Parameter.

With the present example, could it be a matter of how the string is being provided for the parameter keyword?

I'm afraid that I've not been able to reproduce a failing test for integer storage, using a similar approach The example at the compiler explorer might at least illustrate the failing characters/string test.

[spchamp]

I notice that the example fails to compile if defining args_out_2 as beginning from the value initially returned from the local ensure_param_default function [Compiler Explorer]:

  auto const args_out_2 =
        ensure_param_default(args_out, _arg3, [&called_p](auto const&) -> int {
          called_p = true;
          return 12321;
        });

This results in the following error message:

<source>:55:10: err: no matching function for call to 'compose'
   55 |   return param::compose((kw = std::invoke(func, args)), args);
      |          ^~~~~~~~~~~~~~
<source>:101:9: note: in instantiation of function template specialization 'ensure_param_default<tags::test_arg3, (lambda at <source>:101:47), boost::parameter::aux::flat_like_arg_list<boost::parameter::aux::flat_like_arg_tuple<tags::test_arg1, boost::parameter::aux::tagged_argument_rref<tags::test_arg1, std::basic_string<char>>>, boost::parameter::aux::flat_like_arg_tuple<tags::test_arg2, boost::parameter::aux::tagged_argument<tags::test_arg2, const int>>>>' requested here
  101 |         ensure_param_default(args_out, _arg3, [&called_p](auto const&) -> int {
      |         ^
/app/boost/include/boost/parameter/compose.hpp:84:9: note: candidate template ignored: substitution failure [with TaggedArg0 = typename ::boost::lazy_enable_if< ::boost::mp11::mp_if< ::std::is_scalar<int>, ::boost::mp11::mp_true, ::boost::mp11::mp_if< ::std::is_same<typename test_arg3::qualifier, ::boost::parameter::in_reference>, ::boost::mp11::mp_true, ::std::is_same<typename test_arg3::qualifier, ::boost::parameter::forward_reference>>>, ::boost::parameter::aux::tag<test_arg3, const int &>>::type, TaggedArgs = <boost::parameter::aux::flat_like_arg_list<boost::parameter::aux::flat_like_arg_tuple<tags::test_arg1, boost::parameter::aux::tagged_argument_rref<tags::test_arg1, std::basic_string<char>>>, boost::parameter::aux::flat_like_arg_tuple<tags::test_arg2, boost::parameter::aux::tagged_argument<tags::test_arg2, const int>>>>]: no type named 'type' in 'boost::parameter::result_of::compose<boost::parameter::aux::tagged_argument_list_of_1<boost::parameter::aux::tagged_argument<tags::test_arg3, const int>>, boost::parameter::aux::flat_like_arg_list<boost::parameter::aux::flat_like_arg_tuple<tags::test_arg1, boost::parameter::aux::tagged_argument_rref<tags::test_arg1, std::basic_string<char>>>, boost::parameter::aux::flat_like_arg_tuple<tags::test_arg2, boost::parameter::aux::tagged_argument<tags::test_arg2, const int>>>>'
   83 |     ::compose<TaggedArg0,TaggedArgs...>::type
      |                                          ~~~~
   84 |         compose(TaggedArg0 const& arg0, TaggedArgs const&... args)
      |         ^
/app/boost/include/boost/parameter/compose.hpp:13:68: note: candidate function not viable: requires 0 arguments, but 2 were provided
   13 |     inline BOOST_CONSTEXPR ::boost::parameter::aux::empty_arg_list compose()
      |    

Perhaps the value I've returned from the ensure_param_default(...) is not completely an argument pack?

It seemed to match the signature, I'd thought, of (keyword = value, args)

[Lastique]

I'm not very familiar with Boost.Parameter internals, but parameter packs store references to the passed values to avoid copies, if possible. In your example, this is the operator= overload that is being called by kw = ... assignment, and the right-hand argument is an std::string rvalue returned by std::invoke. tag<Tag,T>::type expands here to tagged_argument_rref, which stores a reference to the value internally. This means that the temporary returned by std::invoke/lambda is destroyed after the call to ensure_param_default completes, leaving the reference to the string in args_out dangling.

Boost.Parameter parameter packs are designed to pass parameters to functions and not to be used as regular tuples. This is why storing a reference internally is appropriate, since temporaries created for a function call remain valid until the call returns.

If you want to provide a default value for an argument, you can use the param | default_value or param || default_func syntax. I.e., you would write your wrapper function that accepts Boost.Parameter parameter pack with the defaults you want, then, from within that function, call Boost.Log or whatever other API you are working with underneath.

Alternatively, just collect the parameters you want to pass to Boost.Log as separate variables and then pass them as named parameters to Boost.Log.