--
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/c6fbbdcd-b9fb-475e-863b-0582a771ed2c%40isocpp.org.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAOU91ONHzuSP3CWpS7yRa54sRwcZi6BOus-qp6GhYgxFc1CZjQ%40mail.gmail.com.
I believe that std::any should be made invokable, if an invokable object is stored into it, such as a function pointer, method pointer, or a functor (such as std::function<> and others). This would raise the level of abstraction C++ offers to one comparable to scripting languages, where you can often invoke an arbitrary variable.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/c138266b-9523-41ce-a601-3579a675eab2%40isocpp.org.
From my perspective, the user could easily ignore, that std::any is invokable. I believe that adding a separate class, which would duplicate a lot of what std::any does, would not reflect well on the STL.
2017-03-02 20:41 GMT+01:00 Nicol Bolas <jmck...@gmail.com>:On Thursday, March 2, 2017 at 1:26:01 PM UTC-5, jane...@gmail.com wrote:--I believe that std::any should be made invokable, if an invokable object is stored into it, such as a function pointer, method pointer, or a functor (such as std::function<> and others). This would raise the level of abstraction C++ offers to one comparable to scripting languages, where you can often invoke an arbitrary variable.
But the purpose of `any` isn't to be "comparable to scripting languages". It's for being able to store an object of any (copyable) type and be able to retrieve it in a type-safe way. It's a type-safe `void*` with value semantics.
Adding a function interface to it doesn't help `any` achieve the goal it's setting out to achieve.
If you want to suggest a type that can store any callable and attempt to call it with any arbitrary sequence of parameters and return types (throwing an exception if the given params/return value doesn't match), that's a different type from `any`.
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/c138266b-9523-41ce-a601-3579a675eab2%40isocpp.org.
--
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/CAO9E8GE%3DvpUcB11fSLVS46T0ErB0gOPeYphYSqUvYS7uMknjbA%40mail.gmail.com.
On Thu, Mar 2, 2017 at 12:15 PM, janezz55 . <jane...@gmail.com> wrote:From my perspective, the user could easily ignore, that std::any is invokable. I believe that adding a separate class, which would duplicate a lot of what std::any does, would not reflect well on the STL.It's all a question of your attitude toward C++. Do you want C++ to be like a scripting language or do you want it to be a language where the type system catches mistakes for you at compile time?In my opinion, making a class that either does or doesn't do something when called, depending on what you put inside it, without any way for the compiler to check, would not reflect well on C++.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/9c85aaa8-6ace-45f6-a8fa-b12b1209a53a%40isocpp.org.
From my perspective, the user could easily ignore, that std::any is invokable.
I believe that adding a separate class, which would duplicate a lot of what std::any does, would not reflect well on the STL.
I can tell you as an any semi-expert, that std::any, such as it is, is a resource hog. It mostly allocates from the heap to copy or move an object into it, of course small object optimizations are possible ..., but let's leave that on the side. The only argument to merge this functionality into std::any is because I think invocations of std::any are a "natural" extension of what std::any does, as you can see in almost any scripting language, like lus, python, perl...
Using SFINAE and perhaps other techniques you can easily morph a std::any into std::any_function and vice versa. You can have 2 separate types, essentially, without the user knowing anything about it.
--
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/9c85aaa8-6ace-45f6-a8fa-b12b1209a53a%40isocpp.org.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAMmfjbM5ZdmBPKo4tN80UnwbkfL-bbo5-iFj_-pOMU2c0dPyng%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO9E8GEj8hjctR_AGiJVWHCM_Gt6n1czbo04tH86xUzmuta7iw%40mail.gmail.com.
I think that perhaps the strongest argument in favor of a single type is the stored function's return value. It has to be stored in a std::any itself.
template<typename ReturnType, typename ...Args>
ReturnType any_call(any_function, Args &&...params);
It could be done like that, but returning a std:any makes the class more user friendly, if the result is discarded, for example. There also won't be any need to specify a return type. Exceptions can be thrown later if the returned any is cast to an invalid type.
I believe that std::any should be made invokable, if an invokable object is stored into it, such as a function pointer, method pointer, or a functor (such as std::function<> and others). This would raise the level of abstraction C++ offers to one comparable to scripting languages, where you can often invoke an arbitrary variable. I've prepared 2 examples:
--
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/CAO9E8GFkHwh5-vp6hgt7QtTt-24sJA8ORENf50ha4P%2ByXETRzA%40mail.gmail.com.
Please refrain from comments that are not technologically sound and at the same make you sound like a fanatic.If you want full duck typing on your type system, then please consider using a language that is not C++. And `function<any (vector<any>)>` is exactly what you're asking for, so I don't know why you're so angry at it.
On Fri, Mar 3, 2017 at 11:15 AM janezz55 . <jane...@gmail.com> wrote:
I already wrote what I needed :) function<any(std::vector<any>)> is simply blasphemous.2017-03-03 11:09 GMT+01:00 Giovanni Piero Deretta <gpde...@gmail.com>:On Thursday, March 2, 2017 at 6:26:01 PM UTC, jane...@gmail.com wrote:I believe that std::any should be made invokable, if an invokable object is stored into it, such as a function pointer, method pointer, or a functor (such as std::function<> and others). This would raise the level of abstraction C++ offers to one comparable to scripting languages, where you can often invoke an arbitrary variable. I've prepared 2 examples:
Any is a polymorphic wrapper for any object modeling the CopyConstructible concept. Anything beyond that is out of scope. In fact any doesn't even provide equality or ordering, which would seem very basic.
What you want is std::function (another polymorphic wrapper for types modeling the FunctionObject concept) . If you want fully dynamic behavior (including runtime type checking of parameters), use function<any(std::vector<any>)> and wrap the stored function in an adaptor that does the unboxing of the parameters.
--
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/CAO9E8GFkHwh5-vp6hgt7QtTt-24sJA8ORENf50ha4P%2ByXETRzA%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAPCFJdRYm-e3bartR%2BbNppVa9%3DZYEJB0zua9O1vAz1i4htTaMQ%40mail.gmail.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-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/CAO9E8GE2GR1GQRos5BCUJzLi5yaYup5XegKF253kwet6TFZBjg%40mail.gmail.com.
Show us the actual (i.e. complete) example of why that be useful (and why you wouldn't just use `std::function<void ()>`, or the somewhat proposed function_ref, for that).
On Fri, Mar 3, 2017 at 12:10 PM janezz55 . <jane...@gmail.com> wrote:
Let's say you store a lambda object into std::anystd::any a = [](){};How are you going to obtain the lambda object back? AFAIK it's locked inside the any instance. If std::any had a mechanism of invoking the stored object you could still "reach" it.
--2017-03-03 11:15 GMT+01:00 janezz55 . <jane...@gmail.com>:I already wrote what I needed :) function<any(std::vector<any>)> is simply blasphemous.2017-03-03 11:09 GMT+01:00 Giovanni Piero Deretta <gpde...@gmail.com>:On Thursday, March 2, 2017 at 6:26:01 PM UTC, jane...@gmail.com wrote:I believe that std::any should be made invokable, if an invokable object is stored into it, such as a function pointer, method pointer, or a functor (such as std::function<> and others). This would raise the level of abstraction C++ offers to one comparable to scripting languages, where you can often invoke an arbitrary variable. I've prepared 2 examples:
Any is a polymorphic wrapper for any object modeling the CopyConstructible concept. Anything beyond that is out of scope. In fact any doesn't even provide equality or ordering, which would seem very basic.
What you want is std::function (another polymorphic wrapper for types modeling the FunctionObject concept) . If you want fully dynamic behavior (including runtime type checking of parameters), use function<any(std::vector<any>)> and wrap the stored function in an adaptor that does the unboxing of the parameters.
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/CAO9E8GE2GR1GQRos5BCUJzLi5yaYup5XegKF253kwet6TFZBjg%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAPCFJdTh6k94-FoSYBVBnohxj8eXM2_NHxAgThxZttzqkWjErA%40mail.gmail.com.
Show us the actual (i.e. complete) example of why that be useful (and why you wouldn't just use `std::function<void ()>`, or the somewhat proposed function_ref, for that).On Fri, Mar 3, 2017 at 12:10 PM janezz55 . <jane...@gmail.com> wrote:Let's say you store a lambda object into std::anystd::any a = [](){};How are you going to obtain the lambda object back? AFAIK it's locked inside the any instance. If std::any had a mechanism of invoking the stored object you could still "reach" it.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/a6013d8d-73a6-4f40-bbc9-77e57123f68e%40isocpp.org.
To unsubscribe from this group and all its topics, 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/a6013d8d-73a6-4f40-bbc9-77e57123f68e%40isocpp.org.
--
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/CAO9E8GEDs%2BmqoyCxakK0v-hKoWcBYJE%2B9rdXuNUyGMTRwqPFAw%40mail.gmail.com.
To unsubscribe from this group and all its topics, 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/a6013d8d-73a6-4f40-bbc9-77e57123f68e%40isocpp.org.
--
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/CAO9E8GEDs%2BmqoyCxakK0v-hKoWcBYJE%2B9rdXuNUyGMTRwqPFAw%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAPCFJdSFV30P%3DdEQoooHcn05s6WqBiaV4XpyuQY4P3jLkM5Dqg%40mail.gmail.com.
To unsubscribe from this group and all its topics, 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/a6013d8d-73a6-4f40-bbc9-77e57123f68e%40isocpp.org.
--
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/CAO9E8GEDs%2BmqoyCxakK0v-hKoWcBYJE%2B9rdXuNUyGMTRwqPFAw%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAPCFJdSFV30P%3DdEQoooHcn05s6WqBiaV4XpyuQY4P3jLkM5Dqg%40mail.gmail.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-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/CAO9E8GHrHjykbpVLJv3RVBL7QK9DwcF4gFMF5HP%2B2QFCWvRS4A%40mail.gmail.com.
To unsubscribe from this group and all its topics, 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/a6013d8d-73a6-4f40-bbc9-77e57123f68e%40isocpp.org.
--
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/CAO9E8GEDs%2BmqoyCxakK0v-hKoWcBYJE%2B9rdXuNUyGMTRwqPFAw%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAPCFJdSFV30P%3DdEQoooHcn05s6WqBiaV4XpyuQY4P3jLkM5Dqg%40mail.gmail.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/CAO9E8GHrHjykbpVLJv3RVBL7QK9DwcF4gFMF5HP%2B2QFCWvRS4A%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAPCFJdSHx9cFUfnn4a1tzhmnrpZhZFkP6CFq55NWM6HFLMgO-A%40mail.gmail.com.
To unsubscribe from this group and all its topics, 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/a6013d8d-73a6-4f40-bbc9-77e57123f68e%40isocpp.org.
--
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/CAO9E8GEDs%2BmqoyCxakK0v-hKoWcBYJE%2B9rdXuNUyGMTRwqPFAw%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAPCFJdSFV30P%3DdEQoooHcn05s6WqBiaV4XpyuQY4P3jLkM5Dqg%40mail.gmail.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-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/CAO9E8GHrHjykbpVLJv3RVBL7QK9DwcF4gFMF5HP%2B2QFCWvRS4A%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAPCFJdSHx9cFUfnn4a1tzhmnrpZhZFkP6CFq55NWM6HFLMgO-A%40mail.gmail.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-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/CAO9E8GFfWesTJDsnn9Q%2B2qxtbxN-sqD7yAnPkwkHBHoG9N7Yag%40mail.gmail.com.
When you open your browser the use cases are showing in front of your eyes, JavaScript programs storing functions in a variable. Python, lua and countless other scripts doing the same. I can't believe you haven't seen any of this in practice.
To unsubscribe from this group and all its topics, 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/a6013d8d-73a6-4f40-bbc9-77e57123f68e%40isocpp.org.
--
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/CAO9E8GEDs%2BmqoyCxakK0v-hKoWcBYJE%2B9rdXuNUyGMTRwqPFAw%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAPCFJdSFV30P%3DdEQoooHcn05s6WqBiaV4XpyuQY4P3jLkM5Dqg%40mail.gmail.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-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/CAO9E8GHrHjykbpVLJv3RVBL7QK9DwcF4gFMF5HP%2B2QFCWvRS4A%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAPCFJdSHx9cFUfnn4a1tzhmnrpZhZFkP6CFq55NWM6HFLMgO-A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO9E8GGYCVZ5C6-j_3VOpgBPRkSz%2BBg0bU_%3DE%3D_PFe0X4UOkiw%40mail.gmail.com.
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/CAO9E8GGYCVZ5C6-j_3VOpgBPRkSz%2BBg0bU_%3DE%3D_PFe0X4UOkiw%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAPCFJdQ3nZaF9aUSnFzwE0jm2pSieFCLyJNSzw_bWiDVW0oV4Q%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO9E8GGYCVZ5C6-j_3VOpgBPRkSz%2BBg0bU_%3DE%3D_PFe0X4UOkiw%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAPCFJdQ3nZaF9aUSnFzwE0jm2pSieFCLyJNSzw_bWiDVW0oV4Q%40mail.gmail.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-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/CAO9E8GGM%3D%3DcAn_e4VzDMgwXMbJnwaZvGWbw5gEb8NcQg0mkgNg%40mail.gmail.com.
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/CAO9E8GGYCVZ5C6-j_3VOpgBPRkSz%2BBg0bU_%3DE%3D_PFe0X4UOkiw%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAPCFJdQ3nZaF9aUSnFzwE0jm2pSieFCLyJNSzw_bWiDVW0oV4Q%40mail.gmail.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 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/CAO9E8GGM%3D%3DcAn_e4VzDMgwXMbJnwaZvGWbw5gEb8NcQg0mkgNg%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAPCFJdS9eRWOkpJAPqk8a2sqAOB0VDrQjgtk4H6AFAHJ5obmJw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO9E8GGYCVZ5C6-j_3VOpgBPRkSz%2BBg0bU_%3DE%3D_PFe0X4UOkiw%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAPCFJdQ3nZaF9aUSnFzwE0jm2pSieFCLyJNSzw_bWiDVW0oV4Q%40mail.gmail.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-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/CAO9E8GGM%3D%3DcAn_e4VzDMgwXMbJnwaZvGWbw5gEb8NcQg0mkgNg%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAPCFJdS9eRWOkpJAPqk8a2sqAOB0VDrQjgtk4H6AFAHJ5obmJw%40mail.gmail.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-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/CAO9E8GEhviWUpteV%2BS3u3pDC4oVny2gX3MNRH4o-%2B%2Bx%2B9AXdTg%40mail.gmail.com.
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/CAO9E8GGYCVZ5C6-j_3VOpgBPRkSz%2BBg0bU_%3DE%3D_PFe0X4UOkiw%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAPCFJdQ3nZaF9aUSnFzwE0jm2pSieFCLyJNSzw_bWiDVW0oV4Q%40mail.gmail.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 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/CAO9E8GGM%3D%3DcAn_e4VzDMgwXMbJnwaZvGWbw5gEb8NcQg0mkgNg%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAPCFJdS9eRWOkpJAPqk8a2sqAOB0VDrQjgtk4H6AFAHJ5obmJw%40mail.gmail.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 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/CAO9E8GEhviWUpteV%2BS3u3pDC4oVny2gX3MNRH4o-%2B%2Bx%2B9AXdTg%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAPCFJdT6jP_r6qqd9ukUvyK0rFUPt3S5VWbOeHagKC7czwM8oQ%40mail.gmail.com.
Additional costs are an additional function pointer (or virtual function, whichever the implementer prefers) and another type_id. As a std::any may contain storage for "small object optimization", this might not be significant.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO9E8GGsO2h4OUky3ZS%3DduT-jvCkQqs7OJJXYKa_cQux%3Dmw54A%40mail.gmail.com.
...
On Thursday, March 2, 2017 at 3:15:03 PM UTC-5, janezz55 . wrote:From my perspective, the user could easily ignore, that std::any is invokable.
Can they? Can you provide an implementation of an invokable `any` which has the exact same overhead as a non-invokable one, so long as you don't actually use the invoking interface?
I'm not saying you're wrong, but as someone who is not an expert on `any` implementations, I have my doubts about this statement.
I believe that adding a separate class, which would duplicate a lot of what std::any does, would not reflect well on the STL.
It would duplicate some of the the internals of `any`. But being a different type woudl demonstrate a different semantic meaning to code.
Let's rename `any` to `any_object`. Now let's talk about `any_object` in relation to what you want, which is `any_function`.
What does `any_object` represent, semantically? It represents an implicit agreement between the writer of the function taking the `any` and the person providing the value. Both sides must agree on what type(s) that `any_object` will store, and if there is a disagreement or if one side does the wrong thing, exceptions will fly.
What does your conceptual `any_function` represent, semantically? It represents, not the type-erasure of a value, but the type-erausre of a function call signature. And therefore, if you see a function that takes a parameter of type `any_function`, you immediately know that this function will call the given object.
And therefore, the agreement between us is different. The agreement is not that I will provide one or more implicitly-defined types that you will eventually `any_cast` to. The agreement is that I will provide objects that can be called with one or more implicitly-defined function call signatures, that you will eventually call.
If they represent different agreements, then they clearly should be different types. Even if 99% of the code implementation between them is identical, they still need to be separate. Because the code that takes an `any_function` does not want to perform `any_cast` on the value it takes. It will perform `any_call` instead. And vice-versa: code that takes `any_object` will not perform `any_call` on it.
I wouldn't mind having this in the `<any>` header. But I don't like the idea of grafting such a substantially different use case into an existing object.
Also, a pedantic note. "STL" does not mean "standard library."
> You can always achieve that by depressing performance of an ordinary `any` implementation to match invokable one. It would not have effect on conformance. Only QoI is concerned:)I don't see how performance would be depressed. The moving/copying part would obviously be the same, you can do:void f(){}std::any a(f);today, and you could do it in 2001. So what remains is to add the invoking part, either as std::invoke or as a member function. This does not affect the performance of the existing std::any implementation in any way.
Size increase does not imply performance decrease. As far as arithmetic operators are concerned, there's no need to implement them. There is no bottomless sink problem as regards them and std::any. Also their types are not as elaborate as those of the Callables. Compare "int" and "void(*)()", not to mention the lambda types. Delegates are a recurring theme in C++ ever since the 90s. Even now we have a standard signal/slot implementation proposal. An invokable std::any could make implementing callbacks easier for many people.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAFk2RUZGaH%2BKRrRtA-sdNqYVyo64%2B6OhCSay5JsLTCyYiHS9gQ%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/3298793.lKt8yrbkVB%40tjmaciei-mobl1.
because the number and type of arguments is fixed that way, while std::any can handle any number of arguments of any type, that's why it's called std::any. Say:slots["selected"] = [](int){};slots["selected"](1);would also work.
2017-03-13 15:13 GMT+01:00 Ville Voutilainen <ville.vo...@gmail.com>:On 13 March 2017 at 16:03, janezz55 . <jane...@gmail.com> wrote:
> consider:
>
> std::map<std::string, std::any> slots;
>
> slots["onClick"] = [](){};
>
> slots["onClick"]();
>
> This would work with my proposed augmentation and it is possible with my
> example implementation. Most people don't need much beyond that and it is
> very concise.
And you don't write that as
std::map<std::string, std::function<void()>> slots;
exactly because...?
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAFk2RUZGaH%2BKRrRtA-sdNqYVyo64%2B6OhCSay5JsLTCyYiHS9gQ%40mail.gmail.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 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/CAO9E8GEPORQr8r31NxBtx85TF7_g%3DCLJ%2BHv95oxqTVvDdVP6-Q%40mail.gmail.com.
On 13 March 2017 at 04:18, janezz55 . <jane...@gmail.com> wrote:because the number and type of arguments is fixed that way, while std::any can handle any number of arguments of any type, that's why it's called std::any. Say:slots["selected"] = [](int){};slots["selected"](1);would also work.What aboutslots["what_is_my_arity"] = [](auto...){};? If that's supposed to work, how? (Even if you had a separate any_function type for this idea, it still seems fundamentally unable to handle function templates or overload sets, and it gives you an object with a non-type-safe operator().)Fundamentally I completely agree with other commenters: operator() is *not* special. This is just a special case of a general desire: to lift a concept into a concrete type that type-erases the implementation of the concept. That sure is a useful idea, but this is not the right way to get there.
On segunda-feira, 13 de março de 2017 08:38:24 PDT janezz55 . wrote:Because something must know the actual type. Let me take your example:
> because of information hiding and convenience. Also, why use 2 type
> erasers? That's inefficient.
What happens if I called slos["selected"]()? How about slots["selected"](1.0)?
slots["selected"] = [](int){};
slots["selected"](1);
What should happen here?
a) UB
b) runtime error / exception thrown
c) compile error
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/21674643.T1S6GQCl5Z%40tjmaciei-mobl1.
--
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/ee9704b3-656d-4b2c-84cf-eb03bc0800c5%40isocpp.org.
On 13 March 2017 at 19:25, Nicol Bolas <jmck...@gmail.com> wrote:On Monday, March 13, 2017 at 1:50:19 PM UTC-4, Richard Smith wrote:On 13 March 2017 at 04:18, janezz55 . <jane...@gmail.com> wrote:because the number and type of arguments is fixed that way, while std::any can handle any number of arguments of any type, that's why it's called std::any. Say:slots["selected"] = [](int){};slots["selected"](1);would also work.What aboutslots["what_is_my_arity"] = [](auto...){};? If that's supposed to work, how? (Even if you had a separate any_function type for this idea, it still seems fundamentally unable to handle function templates or overload sets, and it gives you an object with a non-type-safe operator().)
Fundamentally I completely agree with other commenters: operator() is *not* special. This is just a special case of a general desire: to lift a concept into a concrete type that type-erases the implementation of the concept. That sure is a useful idea, but this is not the right way to get there.
Now that's an interesting idea: `any_concept<ConceptName>`, which would synthesize the operations specified by the concept. Of course, that would require two things we don't have: the ability to introspect the elements of a concept, and the ability to pass concepts to templates.
This is a pretty good argument for making a concept something other than just a function/variable, since this would permit us to provide them as template arguments.
Granted, even those two things wouldn't be enough, since we cannot automatically synthesize arbitrary global interfaces.You are basically describing "virtual concepts" as per this work-in-progress proposal (which decided to gothe languae-feature way for argumented reasons: https://github.com/andyprowl/virtual-concepts
--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/ee9704b3-656d-4b2c-84cf-eb03bc0800c5%40isocpp.org.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAOU91ONT037s31FpnZ76VY0D4ye_vhLbjtFp_i84tT1rm7-O8w%40mail.gmail.com.
On 13 March 2017 at 19:25, Nicol Bolas <jmck...@gmail.com> wrote:On Monday, March 13, 2017 at 1:50:19 PM UTC-4, Richard Smith wrote:On 13 March 2017 at 04:18, janezz55 . <jane...@gmail.com> wrote:because the number and type of arguments is fixed that way, while std::any can handle any number of arguments of any type, that's why it's called std::any. Say:slots["selected"] = [](int){};slots["selected"](1);would also work.What aboutslots["what_is_my_arity"] = [](auto...){};? If that's supposed to work, how? (Even if you had a separate any_function type for this idea, it still seems fundamentally unable to handle function templates or overload sets, and it gives you an object with a non-type-safe operator().)Fundamentally I completely agree with other commenters: operator() is *not* special. This is just a special case of a general desire: to lift a concept into a concrete type that type-erases the implementation of the concept. That sure is a useful idea, but this is not the right way to get there.
Now that's an interesting idea: `any_concept<ConceptName>`, which would synthesize the operations specified by the concept. Of course, that would require two things we don't have: the ability to introspect the elements of a concept, and the ability to pass concepts to templates.
This is a pretty good argument for making a concept something other than just a function/variable, since this would permit us to provide them as template arguments.
Granted, even those two things wouldn't be enough, since we cannot automatically synthesize arbitrary global interfaces.You are basically describing "virtual concepts" as per this work-in-progress proposal (which decided to gothe languae-feature way for argumented reasons: https://github.com/andyprowl/virtual-concepts
On segunda-feira, 13 de março de 2017 08:38:24 PDT janezz55 . wrote:
> because of information hiding and convenience. Also, why use 2 type
> erasers? That's inefficient.
Because something must know the actual type. Let me take your example:
slots["selected"] = [](int){};
slots["selected"](1);
What happens if I called slos["selected"]()? How about slots["selected"](1.0)?
What should happen here?
a) UB
b) runtime error / exception thrown
c) compile error
So how would such type erasure work when the signature is not part of the erasing type's definition? `any` works because its type erasure only needs to support one operation: fetching the `type_info` for the original type.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAOHCbis_F30hzC5PD5_K%2BS7egxE5zM8dgXJwabTh3_WWSoeF9A%40mail.gmail.com.
Em segunda-feira, 13 de março de 2017, às 13:48:59 PDT, 'Edward Catmur' via
ISO C++ Standard - Future Proposals escreveu:
> On 13 Mar 2017 15:54, "Thiago Macieira" <thi...@macieira.org> wrote:
>
> On segunda-feira, 13 de março de 2017 08:38:24 PDT janezz55 . wrote:
> > because of information hiding and convenience. Also, why use 2 type
> > erasers? That's inefficient.
>
> Because something must know the actual type. Let me take your example:
>
> slots["selected"] = [](int){};
> slots["selected"](1);
>
> What happens if I called slos["selected"]()? How about
> slots["selected"](1.0)?
> What should happen here?
>
> a) UB
> b) runtime error / exception thrown
> c) compile error
>
>
> b) in both cases. As discussed above, this is trivial to implement and
> incurs zero run time cost.
Except for the part that it's not trivial and has a runtime cost.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/1839045.DBs8OGbG07%40tjmaciei-mobl1.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOZTk-KOz3VDpRV%2Bfdpo6u56Bq%2BmuPncC_%2BfW7m9i0CPFA%40mail.gmail.com.
So how would such type erasure work when the signature is not part of the erasing type's definition? `any` works because its type erasure only needs to support one operation: fetching the `type_info` for the original type.
Also, it's important to remember that you cannot declare a template function to be virtual. So you can't get around this by declaring the `operator()` to be a variadic template.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/4437e2de-8bfb-4d3c-ad90-5efc8ead852a%40isocpp.org.
My thoughts exactly. I'm amazed how complex signal/slot implementations of many C++ applications are, I think my proposal would simplify these.
The small size increase is better than introducing a new language feature (C# delegate comes to mind).
How is providing a specific function call signature a significant part of the complexity of signal implementations in C++? Equally importantly, exactly how does it make sense for two signal receiving functions in the same slot to have different call signatures? Because that's the only difference that your `any` makes: it erases the type of the call signature. If you don't erase that, then you can use `std::function` or similar tools.You need to provide one signal type for each signal, which means more code, which means greater complexity.
They are not allowed to, an exception, assert ... will be raised.
Also, look at Qts MOC preprocessor, a very complex code generator.
The any changes I propose don't erase the call signature,
they simply obtain it automatically, to save the users time.
Usually you don't want type conversions in a signal handler, as they cost time.
To me, the main complexity of C++ signal/slot implementations comes from the fact that C++ has no effective way to remove registered signal handlers without using some sort of handle interface. This is due to the fact that most functors are not equality comparable, and indeed equality comparability doesn't make sense for C++ functors.That's not really relevant here, but my solution to this problem would be to return a lambda as a callback to remove the signal handler after registering it.
On terça-feira, 14 de março de 2017 01:17:21 PDT 'Edward Catmur' via ISO C++
Standard - Future Proposals wrote:If it generates code, then the cost is non-zero, even if not executed (larger
> Because something must know the actual type. Let me take your example:
> > > slots["selected"] = [](int){};
> > > slots["selected"](1);
> > >
> > > What happens if I called slos["selected"]()? How about
> > > slots["selected"](1.0)?
> > > What should happen here?
> > >
> > > a) UB
> > > b) runtime error / exception thrown
> > > c) compile error
> > >
> > >
> > > b) in both cases. As discussed above, this is trivial to implement and
> > > incurs zero run time cost.
> >
> > Except for the part that it's not trivial and has a runtime cost.
>
> A small code size increase, admittedly, but zero extra code executed if the
> feature is not used. As for triviality, that's in the eye of the beholder,
> but I'm certain that any library maintainer presented with the
> specification would consider the implementation trivial.
binaries -> higher cache miss rate).
More importantly, it needs to save some kind of erasure for when the callable
would be used, as a void function taking int is not the same type as a lambda
taking int, and neither is the same as a function taking int and returning a
large structure. That means the sizeof(std::any) has increase and that has a
cost for everyone who uses it.
So, no, the cost is most definitely not zero.
As for triviality, see the erasure above.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/2262188.yk3gOplj8S%40tjmaciei-mobl1.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/f35e957b-0e56-4dbf-b60f-184729350b40%40isocpp.org.
So you see `vector<int>` and `vector<float>` as "more code, which means greater complexity"? Because that's what we're talking about: a different template instantiation.I didn't have that in mind at all. Currently signal/slots outside of Qt's mechanism are used something like:signal_t s<void()> clicked;// ...// a whole bunch of signal declarationsThat can be reduced to a single line, for example:std::map<std::string, std::any> signals;they simply obtain it automatically, to save the users time.
signal_t s<void()> sig1;
signal_t s<void(int)> sig2;
signal_t s<void(float)> sig3;
std::map<std::string, std::any> signals = {
{"sig1", {}},
{"sig2", {}},
{"sig3", {}}};
They can change the signatures of signal handlers without updating code as much as would be necessary otherwise.
So in exactly what way would these `any` changes reduce Qt's MOC complexity with regard to signals/slots? Also, the reasons Qt gives for using MOC for signals/slots doesn't include "the standard library doesn't have a signature-erased `function` type". If they wanted to use one, they could have written one themselves, rather than relying on code generation.It would make that code-generating approach unnecessary.
On terça-feira, 14 de março de 2017 09:42:27 PDT 'Edward Catmur' via ISO C++
Standard - Future Proposals wrote:
> That can be held behind the vptr, or in practice the op handler. Just add
> two vtable slots or ops. (libstdc++ and libcxx use ops; I can't remember
> what MSVC uses. Boost.Any uses for-goodness polymorphism, wow. Still zero
> runtime memory cost.)
>
> As for triviality, see the erasure above.
>
>
> I'd consider that trivial.
Then patch it and you'll see.
Specifically, how to implement the throw case when the parameters don't match.
And do they need to match exactly, or will promotion/demotion rules apply? How
about type conversions, like the string -> string_view case in the other
thread?
I believe that std::any should be made invokable, if an invokable object is stored into it, such as a function pointer, method pointer, or a functor (such as std::function<> and others). This would raise the level of abstraction C++ offers to one comparable to scripting languages, where you can often invoke an arbitrary variable. I've prepared 2 examples:These examples are built around a std::any lookalike, but their functionality could be easily merged into a std.:any, asserts could be substituted for exception throwing and other changes made to make it more std:: palatable.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/84ce2d13-ed47-4734-8cc0-f7e90113e65a%40isocpp.org.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/2678048.5ZDxK9zII1%40tjmaciei-mobl1.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/1976706.iW0ED2DjAJ%40tjmaciei-mobl1.
I beg to differ,
However, whether you are right or wrong, does not matter here. We should be discussing std::any/std::invoke, not Qt or my library or any advantages either might have.
--
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/47819a7d-d22a-463e-8ae8-c04368ec1286%40isocpp.org.
We are really running in circles now.
On Wed, Mar 15, 2017 at 4:42 PM Nicol Bolas <jmck...@gmail.com> wrote:
On Wednesday, March 15, 2017 at 11:23:43 AM UTC-4, janezz55 . wrote:I beg to differ,
Before you get too far in the differing, I should point out that Thiago Macieria is actually one of the developers of Qt. So I'd take his word on it as far as what a Qt tool is intended to do.However, whether you are right or wrong, does not matter here. We should be discussing std::any/std::invoke, not Qt or my library or any advantages either might have.--
But it does matter.
Thus far, the justification for this feature, type-erasing function signatures, has been decidedly lacking. The closest to a useful motivation you've provided is with signals/slots, through your claims that such things are too complicated when you have to provide a function signature.
If we ignore that example, then it ceases to be a motivation. So we have to ask again: why do we need this feature? What purpose does it serve? What problem does it solve?
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.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/47819a7d-d22a-463e-8ae8-c04368ec1286%40isocpp.org.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/2200779.koFCFZkZpI%40tjmaciei-mobl1.
On Tuesday, March 14, 2017 at 4:23:51 AM UTC-4, janezz55 . wrote:My thoughts exactly. I'm amazed how complex signal/slot implementations of many C++ applications are, I think my proposal would simplify these.
How is providing a specific function call signature a significant part of the complexity of signal implementations in C++? Equally importantly, exactly how does it make sense for two signal receiving functions in the same slot to have different call signatures? Because that's the only difference that your `any` makes: it erases the type of the call signature. If you don't erase that, then you can use `std::function` or similar tools.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/cJD8urBWN7c/unsubscribe.
To unsubscribe from this group and all its topics, 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/2663636.SEFX8e3ZWL%40tjmaciei-mobl1.