Allow inline functions to call other inline functions with a lower accessibility level.

[teo-tsirpanis]

Is your feature request related to a problem? Please describe.

Let's say we have a public function foo which uses SRTPs so must be inline. This function has to call a trivial utility function bar that is used from several different parts of the module and does not need to be known outside of the module. Because foo is inline and public, bar has to be public as well, exposing an insignificant implementation detail.

Describe the solution you'd like

If however, bar was private and inline, it could be inlined everywhere foo was used, in a transparent way that does not even imply bar's existence to code outside the module. That's the point of inline functions whatsoever.

Inline functions cannot access constructs with a lower accessibility level than itself, because it would expose hidden code to outsiders. Of course the latter inline function (bar in our case) has to follow that rule despite its accessibility level allowing it. I acknowledge it is kind of counterintuitive.

As for how to implement it, my idea was to keep the reference to toCharacters until the real inlining takes place (when genericUnsigned will be called from a non-inline function). When that happens, the inline functions will have to be recursively expanded.

Describe alternatives you've considered

I can either make bar public but clutter my public API, or manually inline bar's implementation every time it would have been called, but duplicate my code.

Additional context

I am writing a generic high-performance function to parse integers from ReadOnlySpans of characters. In .NET Standard 2.1, I can directly convert the span to an integer without wasting an allocation by converting it to a string first. I abstracted this behavior with a type alias that is a string in all platforms except .NET Standard 2.1 and a function which converts the string to a span in all platforms except .NET Standard 2.1.

type Characters =
    // Soon...
    #if NETSTANDARD_2_1
        ReadOnlySpan<char>
    #else
        string
    #endif

let toCharacters (x: ReadOnlySpan<char>): Characters =
    #if NETSTANDARD_2_1
        x
    #else
        x.ToString()
    #endif

The following piece of code is used thrice: twice for all types of (un)signed integers, and once for all types of floating-point numbers.

let inline genericUnsigned< ^TInt when ^TInt: (static member Parse: Characters * NumberStyles * IFormatProvider -> ^TInt)> name =
    terminal name
        (T (fun _ x ->
            (^TInt: (static member Parse: Characters * NumberStyles * IFormatProvider -> ^TInt)
                (toCharacters x, NumberStyles.Integer, NumberFormatInfo.InvariantInfo))))
        unsignedRegex

I would like to make the toCharacters function private for obvious reasons.
Update: As I was writing this issue, I realised that there is a similar problem with Characters. Characters is a type alias of a public type, not a new type, so no code will be exposed by inlining the type a bit earlier as well.

[abelbraaksma]

I like this request, since I often stumble upon this myself. I'm wondering whether we can take it one step further: allow access to private members from public inlined members.

From a clr standpoint, this isn't problematic, in fact, you can currently get a private member through reflection, and write the IL to call this private member (even with private types). Or would this invalidate PeVerify?

Security wise, I don't really see a problem, as the methods that get inlined on a call site where normally there isn't accessibility to the private member, this is hidden by the inline function and only the compiler would write this code (I mean, it's not that suddenly the private member itself becomes publicly accessible).

Another alternative is that the compiler creates a a public stub, but marked as non-user-code.

Some care needs to go into making sure that any private types, or a curried version of the private method, are not accidentally exposed (I.e.as a return value of the inlined member).

[teo-tsirpanis]

@abelbraaksma, I had thought of that as well, but the CLR (not just PEVerify) will not take it lightly.

Reflection cheeses this safety but is slow, and might be prohibited in certain environments like .NET Framework.

It's true that a public inline function would allow controlled access on a private member, but is still prohibited in the formalism of the CLR's type safety.

As for public stubs I think they defeat the whole purpose of inline functions. It would be better to just create an ordinary function. We should keep in mind that the only case when inline functions must be used is SRTPs.

[abelbraaksma]

Reflection cheeses this safety but is slow, and might be prohibited in certain environments like .NET Framework.

I meant reflection combined with compiling it to a dynamic method. This is nearly as fast as a real method call. And it doesn't suffer from the problems with IL.

BTW, the links you provided are about a now deprecated set of rules. I'm not sure what the rules are for more recent .NET and Core.

But the argument that some security contexts may not allow this is a strong one, I agree that we cannot lightly take that path.

Your proposal to allow inlined private methods only seems to be more viable as a first step.

As for public stubs I think they defeat the whole purpose of inline functions

Not quite. If your inline function calls a private member that's not inlined, a stub created by the compiler will not add overhead (the JIT will optimize it away), and it'll be a hidden member, just like other public members in F# that are currently also auto-generated and public, but inaccessible from F#.

It's not always an optimization to inline everything referenced by an inlined function. And often you will not have access to the function or member if it comes from a library and is protected or virtual (also cases where inline is not allowed with). Besides, you simply may not want to expose the functions you reference in your public inlined function.

[teo-tsirpanis]

I see. We create the method stub as an ordinary method, and the JIT will inline it for us. AggressiveInlining would also be helpful here.

[dsyme]

and does not need to be known outside of the module.

I dontr understand. Consider i

• foo uses bar
• foo is public and inlined
• bar is not inlined.

Then bar definitely needs to be public too, since it's exposed when foo is used from the outside.

You should just inline bar as well in this situation.

I don't see the specific request here that makese sense to me. In any case please reopen at https://github.com/fsharp/fslang-suggestions.

[teo-tsirpanis]

• bar is not inlined.

Maybe my phrasing was unclear, but bar was inline as well.

Simple examples like

let private inline bar() = ()

let inline foo() = bar()

work, but more complex cases like the one I described (calling private inline functions inside an SRTP, which is inside a delegate, which is then passed to a function) result in a compiler error.

Unfortunately I could not create a standalone reproducing snippet.