Conditional Functions

[project-x51]

Hi,

I'm not sure if such a feature exists already so forgive me if this is already a thing.

I propose a function that is only called if a condition is met. Such as function would be ideal for performance optimization in logging applications and possibly others. The idea is that the function definition would include a typically small set of parameters passed to it for the condition and then more parameters that are only passed to it if the condition is met.

The language would then inline the condition check and only setup the stack and call into the function if the condition was true.

So a function call like this...

    public void LogInfo(string Message, params object[] items)
    {
        if (this.MinLogLevel >= LogLevel.Info)
            Logger.Info(Message, items);
    }

Could be declared like this (as an example)

    public conditional (this.MinLogLevel >= LogLevel.Info) void LogInfo(string Message, params object[] items)
    {
        Logger.Info(Message, items);
    }

If a return value other than void was defined we could use the same idea of a default parameter. Eg bool = false.

Does this make sense?

[colejohnson66]

This is already possible. If the method being called is short enough, the JIT will inline it for you. The typical method (no pun intended) of doing so is:

public void DoX(…)
{
    if (DoThing)
        DoXButForReal(…); // <- imagine that this method is hundreds of lines long
}

Again, you won’t see this optimization in the compiler; the JIT will do it for you at runtime. Test it out yourself at https://sharplab.io

[project-x51]

This is already possible. If the method being called is short enough, the JIT will inline it for you. The typical method (no pun intended) of doing so is:

public void DoX(…)
{
    if (DoThing)
        DoXButForReal(…); // <- imagine that this method is hundreds of lines long
}

Again, you won’t see this optimization in the compiler; the JIT will do it for you at runtime. Test it out yourself at https://sharplab.io

Cool tool. Its been a while since I have looked at assembly and I've never written it for the x86. But I don't see the code being optimized in the JIT. Nor is it in-lined in the IL. Not that in-lining the entire function is really the objective.

[colejohnson66]

You’re in debug mode. Many optimizations require release mode.

[timcassell]

From your example, it looks like the purpose is to avoid concatenating a string when the log isn't needed. This is the poster child for Interpolated String Handlers.

[333fred]

I'm curious what else you think it could do? Your example above also would need to generate that check.

[333fred]

And, to be clear, interpolated string handlers can avoid creating any part of the string. See also Stephen Toub's blog post on the topic, and how Debug.Assert avoids all costs related to interpolated strings if the assert didn't fail: https://devblogs.microsoft.com/dotnet/string-interpolation-in-c-10-and-net-6/#debug.assert-without-the-overhead.

[timcassell]

It's not a library, it's a C# 10 feature. If you read further down the article, it mentions

The handler can add a final out bool parameter. Setting that parameter to false indicates that the handler shouldn't be called at all to process the interpolated string expression:

The compiler actually inlines the handler functionality and checks the result of that out parameter before building the string.

[project-x51]

I'm curious what else you think it could do? Your example above also would need to generate that check.

I agree that the check is unavoidable. But calling into a function to do the check could be avoidable. This is the idea.

[333fred]

Well, it avoids 99% of the work building up the string, and it doesn't need to try to find a way to encode arbitrary IL into a method signature then duplicate it at every callsite. That seems like an excellent tradeoff to me.