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

**URL:** <https://discourse.julialang.org/t/mechanism-for-optional-interface-functions-is-this-a-bad-idea/41466>\
**Category:** General Usage\
**Created:** [June 15, 2020, 7:53pm UTC](https://discourse.julialang.org/t/mechanism-for-optional-interface-functions-is-this-a-bad-idea/41466 "2020-06-15T19:53:28Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![zsunberg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zsunberg/32/1883_2.png) [@zsunberg](https://discourse.julialang.org/u/zsunberg)\
**Post date:** [June 15, 2020, 7:53pm UTC](https://discourse.julialang.org/t/mechanism-for-optional-interface-functions-is-this-a-bad-idea/41466/1 "2020-06-15T19:53:28Z")

</div>

Hi all, some of us are working on an interface for reinforcement learning [https://github.com/JuliaReinforcementLearning/CommonRLInterface.jl](https://github.com/JuliaReinforcementLearning/CommonRLInterface.jl). 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

```julia
@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 🙂 it seems like it should be easy to put the backedges in, but has not been done even though it was desired in 2017 [https://github.com/mauro3/SimpleTraits.jl/issues/40](https://github.com/mauro3/SimpleTraits.jl/issues/40))

---

<div class="post-metadata">

**Author:** ![zsunberg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zsunberg/32/1883_2.png) [@zsunberg](https://discourse.julialang.org/u/zsunberg)\
**Post date:** [June 15, 2020, 7:58pm UTC](https://discourse.julialang.org/t/mechanism-for-optional-interface-functions-is-this-a-bad-idea/41466/2 "2020-06-15T19:58:58Z")

</div>

Ah, sorry for the noise! @rejuvyesh directed me here: [https://github.com/JuliaLang/julia/pull/32732](https://github.com/JuliaLang/julia/pull/32732)

---

<div class="post-metadata">

**Author:** ![zsunberg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zsunberg/32/1883_2.png) [@zsunberg](https://discourse.julialang.org/u/zsunberg)\
**Post date:** [June 16, 2020, 8:48pm UTC](https://discourse.julialang.org/t/mechanism-for-optional-interface-functions-is-this-a-bad-idea/41466/3 "2020-06-16T20:48:10Z")

</div>

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](https://github.com/JuliaReinforcementLearning/CommonRLInterface.jl/issues/1).