On `defoverridable` w.r.t inlining

[Wiebe-Marten Wijnja]

I am building a runtime type-checking library. 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

[w...@resilia.nl]

I am still hoping for some guidance on this ^_^.

Currently I am simply using `@compile :inline` to use 'implicit inlining' instead, which works as expected since it attempts to inline all public functions (that are small enough) of the current module.

However, that also has its obvious drawbacks.