Mechanism for optional interface functions - is this a bad idea?

Hi all, some of us are working on an interface for reinforcement learning There will be many interface functions that are optional, and perhaps multiple ways to accomplish similar things. In order to make it easier for algorithm-writers to tell what functions an environment supports, I created a function called provided that acts similar to a trait for every optional function in the interface. It has the exact same usage as Base.applicable, but it is inferrable. I provide a @provide macro that can be used, for example, as follows

@provide CommonRLInterface.clone(env::MyCommonEnv) = deepcopy(env)

to automatically define the trait when the method is written.

If applicable were inferrable, we could just use that instead. If this was a good design pattern, it seems like applicable would be inferrable and could replace or be used in IteratorEltype() in Base. Since it is not used in Base and applicable has not been made inferrable, I am suspicious that there is some problem with the pattern. Am I missing something? Is this a good pattern? Why wasn’t applicable used in the AbstractArray traits? (I guess I still don’t understand why applicable is not inferrable :slight_smile: it seems like it should be easy to put the backedges in, but has not been done even though it was desired in 2017

Ah, sorry for the noise! @rejuvyesh directed me here:

After reading that thread and the ones it is connected to, I still don’t fully understand why applicable and hasmethod are not inferrable, expecially because of the existence of static_hasmethod in Tricks.jl. I am still not 100% sure whether it is a technical issue or an ideological decision to not allow it.

Anyways, I am still not sure whether or not it is a good idea to maintain what is essentially our own shadow applicable with provided. Discussion of the particular application is in this issue.