I am building a runtime type-checking library <https://github.com/Qqwy/elixir-type_check>. The type checks themselves are added at compile time to the module that is compiled to allow compiler optimizations to happen. The library uses `defoverridable` to wrap the existing function with the code that checks its input- and output-types.
Now for this kind of wrapping code it makes sense to tell the compiler that it is OK to inline the inner function if it feels like it, because: 1. it will not be called directly but only ever through the wrapper. 2. In cases where either the function or the wrapping-logic are small, inlining would improve performance and possibly open up further compiler-optimizations. However, there is no clear way to indicate currently that we'd want to allow the function we are overriding to be inlined: Say we are wrapping a function called `add/2`. - Using `@compiler inline: [add: 2]` would end up allowing the *final* function (that includes our wrapping code) to be inlined rather than the overriden function. - Using `@compiler inline: ["add (overridable 1)": 2]` 'kind of' works, but depends on an internal implementation detail. (And it might break if `defoverridable` is used multiple times in the same module.) So my question/request is: Is there a better way to allow inlining in combination with defoverridable right now? If not, can we improve it? Thank you! ~Marten/Qqwy -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/1a1b8614-7a2b-4040-a4b6-8b2290d8f8eeo%40googlegroups.com.
