K-ballo changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar.cct.lsu.edu | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | Buildbot: http://rostam.cct.lsu.edu/ | Log: http://irclog.cct.lsu.edu/
<gnikunj[m]>
I mean, treat foo(int) as foo_i and foo(double) as foo_d or something
<K-ballo>
I don't follow, that's not the problem
<K-ballo>
void x(int); then `x` has obvious type `void(int)`
<gnikunj[m]>
then when I pass foo, check with both foo_i and foo_d. If there isn't enough info, throw a compile time error.
<K-ballo>
but now you add `void x(float);` and do the exact same `x` again, what type does it have?
<gnikunj[m]>
yes that's what I'm trying to resolve with this technique. When there are overloads. Let the compiler change names of those functions internally. So when the function name is passed, the compiler checks with all the overloads. Whichever fits in goes to the function (instead of current error where it can't figure out).
<K-ballo>
no, that can't work
<K-ballo>
you still have to pass all the candidate functions in
<gnikunj[m]>
And "fits in" can be checked with something like std::invoke_result<F, args...>
<K-ballo>
those functions already have different names internally, their names is never a problem
<K-ballo>
the problem is that a single expression maps to those multiple functions with different internal names
<K-ballo>
and that at different points in time, that same expression maps to different sets
<gnikunj[m]>
yes, and the solution is to try all those internal names to see which one fits
<K-ballo>
no
<gnikunj[m]>
why not
<gnikunj[m]>
what problems does it bring?
<K-ballo>
that's type deduction going in the opposite direction, makes no sense for C++
<K-ballo>
and it doesn't even solve the general problem of wanting to call overloads
<gnikunj[m]>
why does it not solve?
<K-ballo>
the proper solution is to have an internal type that represents the overload set
<K-ballo>
because you can only represent one target
<gnikunj[m]>
as long as the implementation facilitates enough info to know the overload, things should be just fine
<K-ballo>
now if you call `f(0)` and `f(0.)` you'll call the same function twice, that's not how overloads work
<gnikunj[m]>
no, that's not what I meant
<K-ballo>
you said "try each one" and "whatever fits"
<gnikunj[m]>
if there is an overload, only then check within the overloaded set
<gnikunj[m]>
and then yes if `f(int)` and `f(double)` exist, check which one fits in
<K-ballo>
trying/fitting is the wrong aproach, it flows backwards
<K-ballo>
you pass both fs to the function, and then at each call site you perform overload resolution for the set
<gnikunj[m]>
that could be one way of implementing it too
<K-ballo>
that's the one way that works within the C++ expression model
<gnikunj[m]>
I can see that now :/
<gnikunj[m]>
has it been discussed within the community btw?
<K-ballo>
I'm sure it has been
<gnikunj[m]>
I'd very much like to raise a proposal for it, if it hasn't :D
<K-ballo>
I remember participating in discussions on the subject in the early 2000s
<K-ballo>
it's been discussed within the committee as well
<K-ballo>
the changing of types for the expression depending on context is not well received, it will need call site anotation
<gnikunj[m]>
exactly how long have you been programming?
<gnikunj[m]>
I had no clue programs existed in early 2000s lol
<K-ballo>
however they've also strongly rejected clean call site annotation, like `[]foo`
<K-ballo>
they say it's too much of a land grab for such a borderline feature
<gnikunj[m]>
damn, I see
<K-ballo>
so you end up with a LIFT(foo) macro that does effectively the same, and it works fine
<K-ballo>
chances are you are better off not defining those kind of overload sets in the first place, but note the exact same problem applies to function templates
<K-ballo>
template <typename T> void foo(T); doesn't have a type either, that's kinda the point
<gnikunj[m]>
yes, I have personally witnessed the function templates problem
<K-ballo>
so you just wrap it in a lambda and call it a day
<gnikunj[m]>
just that I was curious to see how things work out if I have an overload set
<K-ballo>
if our lambdas weren't so verbose it wouldn't even be a problem
<K-ballo>
at the same time, while the committee calls for terse lambda syntax, they keep rejecting all the candidates too
<gnikunj[m]>
lol
<gnikunj[m]>
can I attend committee meetings btw?
<gnikunj[m]>
are they free?
<K-ballo>
face to face ones? sure, but there won't be any for a while
<gnikunj[m]>
aah, crap. When do they plan to get back to face to face one's?
<K-ballo>
virtual ones, you'd need the chair to invite you since you don't participate already
<gnikunj[m]>
I suppose you cannot send me the invite?
<K-ballo>
I'm not chairing any call
<gnikunj[m]>
:/
<K-ballo>
you don't need to be on the calls to participate in the discussions
<K-ballo>
and once you start participating in the discussions, the chairs will invite you to the calls
<gnikunj[m]>
ohh, how can I participate in the discussions?
<K-ballo>
each paper lists the author's email at the top, for discussion
<K-ballo>
and there are some other forums in which authors discuss proposals you may join
hkaiser has joined #ste||ar
hkaiser has quit [Read error: Connection reset by peer]
hkaiser has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
Vir has quit [Ping timeout: 272 seconds]
Vir has joined #ste||ar
hkaiser has quit [Quit: bye]
diehlpk_work has joined #ste||ar
diehlpk_work_ has quit [Ping timeout: 264 seconds]
diehlpk_work has quit [Remote host closed the connection]