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.
- Jonathan M Davis
