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/
<hkaiser>
K-ballo: btw: using void tag_invoke(...) = delete; as the poison pill breaks MSVC
<K-ballo>
I'm not even sure how the segmented iterator case is even supposed to work with the kind of dispatch tag_invoke (as proposed) does, since there's no associated namespace for "all the iterators that satisfy segmented iterator"
<hkaiser>
K-ballo: we assume they are in a special namespace
<K-ballo>
all segmented iterators must be in some predefined hardcoded iterator?
<hkaiser>
at this point yes :/
<K-ballo>
this stinks
<hkaiser>
nod
<K-ballo>
all the customization point machinery when no customization is expected nor desired, associated namespace lookup where only a specific hardcoded namespace is supported
<K-ballo>
I'll wait to hear about that 3 level use case, to see if something can be done about it
<hkaiser>
nod
<K-ballo>
at the very least, this thing should be called anything but tag_invoke
<hkaiser>
ok
<hkaiser>
K-ballo: so you main beef is the name?
<K-ballo>
no, the whole thing sounds misguided
<hkaiser>
K-ballo: I wouldn't go that far
<K-ballo>
it does explain why you need three different implementations
<hkaiser>
I think 'nned' is the wrong term here
<K-ballo>
the problem with the name is that it's chosen to mean something very specific to both users and compilers, and these uses of the name mean neither
<hkaiser>
those are convenience tools
<K-ballo>
if a tag_invoke eventually does get accepted, this thing will conflict both in adl name and in user expectations
<hkaiser>
fair
<K-ballo>
naming it something else solves that
<hkaiser>
Rene called it duck_invoke ;-)
<K-ballo>
duck_invoke was the name of a tag_invoke implementation
<hkaiser>
yes
<K-ballo>
his, apparently
<hkaiser>
yes
<K-ballo>
I suspect we don't care about the goals of tag_invoke at all, but rather want some sort of overload refinement (+ nice objects)
<hkaiser>
the executor APIs are CPOs, however (async_execute and friends
<hkaiser>
the algorithms not so much
<K-ballo>
those sound like they could actually be CPs
<K-ballo>
using tag_invoke for CPs is a good idea, but it shouldn't ever need the extra levels
<K-ballo>
if I define my own executor it's reasonable that I may want to override async_execute (or go with the default based on some other stuff mine models)
hkaiser has quit [Quit: bye]
K-ballo has quit [Quit: K-ballo]
diehlpk_work has quit [Remote host closed the connection]
<ms[m]>
K-ballo: hkaiser, you covered one of the use cases of the fallback pretty thoroughly... Another one is customization based on the execution policy
<ms[m]>
And you're right that right now the fallback is odd but with concepts (iiuc) we wouldn't need it
<ms[m]>
The override on the other hand I added for wording in p0443 which says that member functions should be preferred even if free functions
<ms[m]>
I may have missed a better way of achieving that or just plain misinterpreted the proposal as well (and the proposal obviously doesn't talk about tag_invoke, so it's not 100% the same anyway)
<ms[m]>
and the fallback/override versions should only ever have one implementation, so those would maybe not need the full machinery for customization
Yorlik has joined #ste||ar
hkaiser has joined #ste||ar
<ms[m]>
gnikunj: btw, related to your resiliency work, it might be interesting for you to have a look at wg21.link/p0443 section "2.9 Appendix: The retry Algorithm"
<gnikunj[m]>
ms woah!
jehelset has joined #ste||ar
<rachitt_shah[m]>
Hey everyone!
<rachitt_shah[m]>
Thank you for accepting me as the technical writer for GSoD!
<rachitt_shah[m]>
I would go through all the materials provided by hkaiser in the mail, and see you folks on the 20th :D
<hkaiser>
rachitt_shah[m]: well, it wasn't me bu ms[m], but anyways - welcome!