Consider supporting method definitions in concepts about dyno HOT 3 CLOSED

I'd argue that there is nary a case where dyno::T is not in the parameter list. If there is some weird case then simply ignoring the first param should not be a problem.

If that is true then why not make it always first?

Also this would be cool:

poly["draw"_s](std::cout);

On a sort of related note, I have been using different types of keys with Dyno like hana::type to signal events.

from dyno.

I'd argue that there is nary a case where dyno::T is not in the parameter list. If there is some weird case then simply ignoring the first param should not be a problem.

If that is true then why not make it always first?

Because a function could want to be dispatched on a different argument than the first one, for example:

int operator+(int, MyType&);

On a sort of related note, I have been using different types of keys with Dyno like hana::type to signal events.

Interesting, I hadn't thought of that but it's certainly cool that this works. I expect this should work with arbitrary Hana compile-time Comparables.

from dyno.

Because a function could want to be dispatched on a different argument than the first one, for example:

int operator+(int, MyType&);

Perhaps we are talking about different things. When I look at all of the Dyno examples of concept map implementations as well as every Rust Trait implementation I can find, there is always self at the front of the argument list.

The placeholder AFAICT is there for the storage value AKA self, and the user never calls the function with the signature directly unless they are working with poly directly which is just crazy. 😛

Maybe I am missing something. I'll have to play with it some more.

I'd like to see an example if you have time, but I know there is the conference coming up.

from dyno.