Добрый вечер. Упрощенно имеется следующий код: void send(const Type & type,

Message && msg)
{
send_impl(type, std::move(msg));
}
void send_impl(const Type & type, Message && msg)
{
//...
}

После msg идет еще 1-3 параметра в зависимости от перегрузки.

Возникла необходимость помимо type (std::string) передавать также tags (std::set) и meta (std::map<string, string>), при этом хотелось бы не портить текущий интерфейс и также отдавать все одним аргументом.
Из этого родилось следующее:
https://codeshare.io/2pdJz9

Вопросы вот какие:
1. Можно ли как-то более явно показать, какие параметры ожидаются в тупле, вроде std::tuple<Type &, Tags &, Meta &> с сохранением преимуществ forward_as_tuple?
2. Можно ли как-то передать эту туплю в send_impl без темлейтов и распаковки, если send_impl лежит в .cpp файлике
3. Может я вообще не туда воюю и есть другой более адекватный подход?

П.С. Сделать еще несколько перегрузок, которые принимают теги и мету я как бы и могу, но хочется дать возможность отдавать только тип/только теги/только мету/мету и теги
С учетом того, что в методе send кроме приведенных в примере параметров есть еще, а также уже есть несколько перегрузок, мне кажется такой подход только раздует код и на местах вызова это будет кошмар.
П.П.С. Делать структурку и класть в нее перед передачей не хочется, ибо копии довольно дорогие и это хайлоад.

1) Можно через специализацию проверить корректность набора параметров в паке. Я написал с использованием C++20 исключительно для демонстрации идеи, он довольно легко переписывается для совместимости с более старыми стандартами

@Indev29, немного обновил пример с демонстрацией. Пользователь может вызвать send с использованием forward_as_tuple только если tuple содержит корректную последовательность типов. Для простоты примера я изменил код так, что возможны висячие ссылки внутри send_impl, если это нежелательное поведение — стоит в is_valid_arg_sequence_helper_v потребовать соответствие точному ссылочному типу и не вызывать его через remove_cvref

Я немного не понял, в каком случае будут висячие ссылки?

Со стороны send_impl мы могли бы ожидать, что наши параметры — не временные объекты и сохранить куда-нибудь ссылку во вне. В случае, требуй мы точного типа, пользователь был бы вынужден не передавать временные объекты. Но, кажется, этому подвержен и оригинальный код, так что полагаю, мой пример корректен

Да, ваш пример корректен, в оригинальном коде это сделано осознанно. Считаем, что на вопрос с проверкой tuple ответ получен :)

Касательно второго вопроса — мне не понятна цель, реализация send_impl может лежать в cpp файле, поскольку это не шаблонная функция

Да, в случае если tuple распаковывается в три аргумента. Но туплю туда не отдать, придется делать темплейт

Я всё ещё не понял, в чём именно проблема текущего кода — наличие функции-враппера send и желание её логику перенести непосредственно в send_impl?

Нет, просто три аргумента в send_impl смущают, если бы туда прямо tuple уходило, было бы, ну, целостнее, что ли

Ну, во-первых, мне не понятна эта проблема. И уж если хочется сгруппировать аргументы по смыслу, std::tuple здесь — худший кандидат, во-вторых, можно объявить в качестве аргумента конкретное инстанцирование std::tuple, это не потребует делать функцию шаблонной

А какие еще варианты помимо tuple есть для объединения аргументов? Структура - это либо копии, либо висящие ссылки, если временный объект отдается. Ну то есть можно конечно написать конструкторы для всех комбинаций и сохранять или ссылку, или делать move для rvalue, но как-то много получается, а хочется все таки без оверхеда. Ваш вариант я изначально хотел делать вместо forward_as_tuple, но насколько я понимаю, нельзя просто так сделать std::tuple<const T&> на временный объект - тоже висящая ссылка получается.

Вообще, как бы вы сделали передачу аргументов таким образом? Или скорее передавали бы как три отдельных аргумента и не стали заморачиваться?)

Я бы принимал по значению. На вызывающей стороне пользователь сам может решить, хочет он копию или мув. И я бы предпочёл структуру, у которой поля имеют осознанные имена, если действительно параметров так много, что необходимо их группировать А с точки зрения проблем висячих ссылок вариант с приёмом tuple, содержащего ссылки совершенно ничем не будет отличаться от варианта с приёмом ссылок. У вас в любом случае будут возможны висячие ссылки, если вы их куда-то сохраните. Самоё надёжное — принимать по значению