Kinds of containers

[Jonathan M Davis via Digitalmars-d]

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