template <class... Args>
void foo(void(*func)(Args...), std::tuple<Args...> args)
{
func(auto{ ... } = args);
}
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0d627ddf-dec9-4051-abaf-e6e6f8dbeaaa%40isocpp.org.
template <class T>
constexpr auto struct_to_fw_tuple(T& any_struct)
{
return std::forward_as_tuple(auto&{...} = any_struct);
}
template <class F, class Tuple>
constexpr decltype(auto) apply(F&& func, Tuple&& tuple)
{
return std::invoke(std::forward<F>(func), auto&&{...} = tuple);
}
Hey,
Yeah I'm aware of std::apply but it still only operates on std::tuple. If you have your own structure and you want to decompose it, there's no generic way to do so.
The tuple need not be std::tuple, and instead may be anything that supports std::get and std::tuple_size; in particular, std::array and std::pair may be used.
Hi Richard,
std::apply doesn't just operate on std::tuple; it uses std::get and std::tuple_size, which is the same method by which you can add structured binding support to your own class (unless the proposal has been updated since I last looked).
Thanks,To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6867504e-d4e5-4e2b-859c-3040f7cdc05f%40isocpp.org.
-- Simon Brand Staff Software Engineer Codeplay Software Ltd Level C, Argyle House, 3 Lady Lawson St, Edinburgh, EH3 9DR Tel: 0131 466 0503 Fax: 0131 557 6600 Website: http://www.codeplay.com Twitter: https://twitter.com/codeplaysoft This email and any attachments may contain confidential and /or privileged information and is for use by the addressee only. If you are not the intended recipient, please notify Codeplay Software Ltd immediately and delete the message from your computer. You may not copy or forward it, or use or disclose its contents to any other person. Any views or other information in this message which do not relate to our business are not authorized by Codeplay software Ltd, nor does this message form part of any contract unless so stated. As internet communications are capable of data corruption Codeplay Software Ltd does not accept any responsibility for any changes made to this message after it was sent. Please note that Codeplay Software Ltd does not accept any liability or responsibility for viruses and it is your responsibility to scan any attachments. Company registered in England and Wales, number: 04567874 Registered office: 81 Linkfield Street, Redhill RH1 6BY
I believe that with variadic decomposition you would only be able to use it for classes which only have public member data (or have those data members in a single direct base class). For any class without that property, you'd still need to write implementations of get and tuple_size. So the main benefit of your suggestion would be removing the need to implement a couple of functions for a small set of classes, but to get that it's mandating a language change and some new syntax.
I do like the idea of the proposal, but I think that the costs
outweigh the benefits over the std::apply solution.
-- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org. To post to this group, send email to std-pr...@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c28ca0ca-b59d-4e06-8c79-52f7cd859a49%40isocpp.org.
Proposal:
template <class... Args>
void foo(void(*func)(Args...), std::tuple<Args...> args)
{
func(auto{ ... } = args);
}The syntax is questionable, but I wanted it to follow the structured bindings syntax as close as possible. The auto keyword can have const, l-value and r-value reference modifiers which will be appended to each argument. Also, the decomposition can only be used within a function/constructor call.
template <class F, class... Args>
void foo(F func, std::tuple<Args...> tup)
{
auto& [args...] = tup;
func(args...);
}
template <class F, class... Args>
void foo(std::tuple<Args...> args)
{
func([:]args...);
}
From: Simon Brand Sent: Wednesday, October 12, 2016 7:31 AM Reply To: std-pr...@isocpp.org Subject: Re: [std-proposals] Variadic decomposition |
Should we just make get and tuple_size automatically work on all PODs?
-- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-pr...@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c28ca0ca-b59d-4e06-8c79-52f7cd859a49%40isocpp.org.
-- Simon Brand Staff Software Engineer Codeplay Software Ltd Level C, Argyle House, 3 Lady Lawson St, Edinburgh, EH3 9DR Tel: 0131 466 0503 Fax: 0131 557 6600 Website: http://www.codeplay.com Twitter: https://twitter.com/codeplaysoft This email and any attachments may contain confidential and /or privileged information and is for use by the addressee only. If you are not the intended recipient, please notify Codeplay Software Ltd immediately and delete the message from your computer. You may not copy or forward it, or use or disclose its contents to any other person. Any views or other information in this message which do not relate to our business are not authorized by Codeplay software Ltd, nor does this message form part of any contract unless so stated. As internet communications are capable of data corruption Codeplay Software Ltd does not accept any responsibility for any changes made to this message after it was sent. Please note that Codeplay Software Ltd does not accept any liability or responsibility for viruses and it is your responsibility to scan any attachments. Company registered in England and Wales, number: 04567874 Registered office: 81 Linkfield Street, Redhill RH1 6BY--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/bf68a3f3-79af-eac4-4a04-f1be2920ded7%40codeplay.com.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20161012152934.4882513.63206.18280%40gmail.com.
That sounds like a good possibility. I'd also be interested in
co-authoring a proposal about it, although it's not something I've
done for the C++ standard before.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYiUZqbEpYYJWkQvDG58pYZA%3D_5s4Vkc4n5_fMvOFskVw%40mail.gmail.com.
Should we just make get and tuple_size automatically work on all PODs?
First, to the folks pointing at std::apply / std::invoke... those can't
call constructors. They are not sufficient.
On 2016-10-14 11:09, Matthew Woehlke wrote:
> On 2016-10-14 10:57, D. B. wrote:
>> On Fri, Oct 14, 2016 at 3:52 PM, Matthew Woehlke wrote:
>>> First, to the folks pointing at std::apply / std::invoke... those can't
>>> call constructors. They are not sufficient.
>>
>> That's what std::make_from_tuple is for.
>
> Please show the library equivalent of this:
>
> auto x = Foo{[:]t1..., [-1]t2, [0]t2, [2:-1]t2..., v};
...not to mention:
// let 'vec' be equivalent to an array of T
auto dot = T{1} * [:]vec...;
auto manhattan_distance = T{0} + std::abs([:]vec)...;
Being able to turn a tuple-like¹ into a parameter pack is MUCH more
useful than having to keep creating one-off library functions to do the
same thing.
On Fri, Oct 14, 2016 at 8:24 AM, Matthew Woehlke <mwoehlk...@gmail.com> wrote:On 2016-10-14 11:09, Matthew Woehlke wrote:
> On 2016-10-14 10:57, D. B. wrote:
>> On Fri, Oct 14, 2016 at 3:52 PM, Matthew Woehlke wrote:
>>> First, to the folks pointing at std::apply / std::invoke... those can't
>>> call constructors. They are not sufficient.
>>
>> That's what std::make_from_tuple is for.
>
> Please show the library equivalent of this:
>
> auto x = Foo{[:]t1..., [-1]t2, [0]t2, [2:-1]t2..., v};
...not to mention:
// let 'vec' be equivalent to an array of T
auto dot = T{1} * [:]vec...;
auto manhattan_distance = T{0} + std::abs([:]vec)...;
Being able to turn a tuple-like¹ into a parameter pack is MUCH more
useful than having to keep creating one-off library functions to do the
same thing.Agreed, but there are fundamental semantic problems that you'd need to overcome before anything like this could get into the language. So while it looks really nifty, I would strongly discourage anyone from saying "Oh, we should JUST standardize something like this and then we don't need (some other achievable library feature) anymore."
There's no such thing as JUST standardizing Matthew's syntax as currently proposed.See my previous posts in this grouphttps://groups.google.com/a/isocpp.org/d/msg/std-proposals/ajLcDl8GbpA/TygOgRe4AwAJ (on blowing up packs of packs)https://groups.google.com/a/isocpp.org/d/msg/std-proposals/ajLcDl8GbpA/d-REDXv2BwAJ (on blowing up packs of packs)https://groups.google.com/a/isocpp.org/d/msg/std-proposals/KW2FcaRAasc/Go39E_4bGAAJ (on syntactic ambiguity)and the following example code.int main() {std::tuple<int> t1 { 1, 2, 3 };std::tuple<int,int> t2 { 4, 5, 6 };std::tuple<int,int,int> t3 { 7, 8, 9 };auto tt = std::make_tuple(t1, t2, t3); // a tuple of tuplesf([:]tt ...); // f(t1, t2, t3);f(g([:]tt) ...); // f(g(t1), g(t2), g(t3));f(g([:]tt ...)); // f(g(t1, t2, t3));f(g([:][:]tt ...) ...); // f(g(1,2,3), g(4,5,6), g(7,8,9)); ???f(g([:][:]tt ... ...)); // f(g(1, 2, 3, 4, 5, 6, 7, 8, 9)); ??????; // f(g(1,4,7), g(2,5,8), g(3,6,9)); ??????; // f(g(1, 4, 7, 2, 5, 8, 3, 6, 9)); ???}
f(g(1,2,3), g(4,5,6), g(7,8,9));
f(std::apply(g, [:]tt)...);
f(g(1, 2, 3, 4, 5, 6, 7, 8, 9));
f(g([:]std::flatten_tuples([:]tt...)...));
f(g(1,4,7), g(2,5,8), g(3,6,9));
f(std::apply(g, [:]std::zip_tuples([:]tt...))...);