On 10/21/2015 02:32 PM, Jonathan M Davis wrote:
On Wednesday, 21 October 2015 at 18:24:30 UTC, Robert burner Schadek wrote:
On Wednesday, 21 October 2015 at 17:23:15 UTC, Andrei Alexandrescu wrote:
Even simpler, hasMethod!(Container, "append") -- Andrei
I know this goes against your talk at DConf, but having to write
string parameters does not feel good. I'm will properly not be the
only one who will mistype "apend" and wonder why the other template
function will be chosen. I rather have the compiler scream at me
telling me there is no symbol hasApend. And hasAppend!Container is
less typing than hasMethod!(Container, "append").
The other concern is that hasMethod isn't going to be checking anything
other than the name, whereas a hasAppend could actually check that the
function accepts the right arguments and returns the correct type.
And it's not like the list of the functions to check for is going to be
infinite. It needs to be a known list of functions where each of those
functions has a signature that meets certain requirements. You can't
just be checking for a random function name and expect it to do what you
want. So, having a list of explicit traits to use for testing for the
expected set of functions will both allow for the tests to be more
thorough than simply checking the name, _and_ it will serve as a way to
help document what the list of expected functions is for a particular
domain.
I really think that using hasMethod by itself like that is getting too
ad hoc and doesn't really benefit us over having an explicit list of
traits for the specific domain that we're dealing with. I totally buy
that testing for each of the specific functions rather than trying to
put all of that information in the type itself (e.g.
ContainerWithAppendAndRemove) simply isn't going to scale, but I don't
at all buy that using hasMethod to test for the existence of member
functions is a good way to go.
I'd say let's first have a Pope before becoming more Catholic than him.
-- Andrei
