Good talk! I strongly agree that this is *not* just an issue for library authors. Especially with ranges coming, it would be very useful to have a cleaner, more succinct way to pass operators to algorithms. Something like the solutions discussed at the end would be a huge win for doing functional programming in C++.
Good talk Simon. However I was expecting to see older proposals solving this issue and why the committee rejected them. I've my own reasons, but It is not clear from the presentation why do you find good f([]foo) and not f(foo{})? I understand that foo without more qualifications could represents an overload set in some future language, however, today it is not an object that represents the overload set, it is either a pointer to the function if there is only one or ambiguous if there are more overloads. I agree that we could do the implicit conversion from a symbol foo to his overload set when we are expecting an overload set. However having to add in the language functions that expect an overload set is something weird to me. The function is expecting a function that takes some specific parameters not an overload set. I want to state this clearly at the interface level, and I cannot without paying more that I'm ready to do. As we are dreaming today, I would like to be able to express that my algorithm f can take any function taking an int and returning an int. void f( ((int) -> int) fct); When I use int foo(int); // (1) int foo(std::string); // (1) f(foo); I would expect that the compiler will use the overload of foo that respects the constraint of f. (int) -> int would be a short hand for a template template void f(F&& fct); The question is how to define a function taking a function that takes either an int or an std::string and returns an int void f( ( (int) -> int | (std::string) -> int) fct); Here we could take advantage of an implicit conversion of foo to this kind of types. I don't understand what overload_set is. Just my 2 cts
![Make It Fixable: Preparing for Security Vulnerability Reports - Patricia Aas [ CppCon 2018 ]](http://i.ytimg.com/vi/IupP8AFrOJk/mqdefault.jpg)
![Make It Fixable: Preparing for Security Vulnerability Reports - Patricia Aas [ CppCon 2018 ]](/img/tr.png)
Good talk! I strongly agree that this is *not* just an issue for library authors. Especially with ranges coming, it would be very useful to have a cleaner, more succinct way to pass operators to algorithms. Something like the solutions discussed at the end would be a huge win for doing functional programming in C++.
Good talk Simon. However I was expecting to see older proposals solving this issue and why the committee rejected them.
I've my own reasons, but It is not clear from the presentation why do you find good f([]foo) and not f(foo{})?
I understand that foo without more qualifications could represents an overload set in some future language, however, today it is not an object that represents the overload set, it is either a pointer to the function if there is only one or ambiguous if there are more overloads.
I agree that we could do the implicit conversion from a symbol foo to his overload set when we are expecting an overload set. However having to add in the language functions that expect an overload set is something weird to me. The function is expecting a function that takes some specific parameters not an overload set.
I want to state this clearly at the interface level, and I cannot without paying more that I'm ready to do.
As we are dreaming today, I would like to be able to express that my algorithm f can take any function taking an int and returning an int.
void f( ((int) -> int) fct);
When I use
int foo(int); // (1)
int foo(std::string); // (1)
f(foo);
I would expect that the compiler will use the overload of foo that respects the constraint of f.
(int) -> int
would be a short hand for a template
template
void f(F&& fct);
The question is how to define a function taking a function that takes either an int or an std::string and returns an int
void f( ( (int) -> int | (std::string) -> int) fct);
Here we could take advantage of an implicit conversion of foo to this kind of types.
I don't understand what overload_set is.
Just my 2 cts
More than 5 years later, nothing has been fixed :(
The special deduction rule makes overload_set unusable for std::function, function_ref etc.
the person who asked Simon Brand has deragatory tones while Simon puts his opinon regarding the overload_set though
"he/him". Good to know.