Feature: Conditional Evaluation via Inlining

[WalkerCodeRanger]

Consider a function like:

public static class BoolExtensions
{
    /// <summary>
    /// The logical relation implies (i.e. X implies Y means that if X is true then Y must be true).
    /// </summary>
    [Inline(export: true)]
    public static bool Implies(this bool self, bool other) => !self || other;
}

It would be great if there was a way to make this boolean connective short-circuiting. With a couple of additional features to inlining, it would be!

Option A

First, the inlining would need to optimize away lambdas and/or expression trees. That is, InlineMethod.Fody should guarantee that when the below methods are inlined, a lambda parameter should be inlined out of existence while preserving the semantics.

    [Inline(export: true)]
    public static bool Implies(this bool self, Func<bool> other) => !self || other();

    [Inline(export: true)]
    public static bool Implies(this bool self, Expression<Func<bool>> other) => !self || other.Compile()();

That provides short-circuiting. But if this were called from a project that didn't have InlineMethod.Fody properly installed, then the original method would be called, introducing the overhead of the lambda. We can't use [Inline(InlineBehavior.Remove, export: true)] because then the method is missing when we try to compile projects dependent on it. Unfortunately, I can't think of a way to enforce this at compile time. But, an option could be added like InlineBehavior.Throw, which would replace the body of the method with throw InvalidOperationException(). That way the mistake would be found at runtime.

Option B

In some ways this is cleaner, but it makes the function more magical to call. An additional attribute could be added to the package to mark parameters that should be treated this way, even without lambdas. In programming language terms, this is "call by need." So it would be something like:

    [Inline(export: true)]
    public static bool Implies(this bool self, [CallByNeed] bool other) => !self || other();

And that could be called just like any other method (e.g. a.Implies(b)) but would then be short-circuiting when inlined. Something like InlineBehavior.Throw would still be needed.

[oleg-st]

a.Implies(b) will became !a || b after inlining which is short-circuiting in c# already.

[WalkerCodeRanger]

No, I've tested, and that does not cause short-circuiting. A method call evaluates all arguments before making the call. When inlining the generated code follows that and assigns each argument into a variable before the expression is evaluated. While the expression is short-circuiting, all its arguments have already been evaluated, so it doesn't short-circuit the evaluation of the second argument.

[oleg-st]

Yes you are right, if the parameter is a method call, it will be called before the expression is evaluated. To solve the problem we need to

1. rewrite method Implies with branch
2. move parameter evaluation to the place of use (inline parameter)

[oleg-st]

See
https://github.com/oleg-st/InlineMethod.Fody/blob/master/src/InlineMethod.Tests.AssemblyToProcess/LateEvaluation.cs

Caller and Inlined will become the same.

[oleg-st]

InlineParameter released in 0.8.3

[WalkerCodeRanger]

Using v0.8.3, the InlineParameter attribute is added, and I think it makes sense and works as expected. However, the obvious implementation of using || or && inside the inlined method doesn't work because the C# compiler optimizes it to a non-shortcircuiting implementation. One must use if as you've done in your test code. Please add documentation about what the InlineParameter does, this potential pitfall, and the need to unit test the correct behavior.

[oleg-st]

Could you clarify about InlineBehavior.Throw? I don't understand the idea.
If we replace the body, we can't inline the method anymore. It makes export attribute useless.

[WalkerCodeRanger]

Re: InlineBehavior.Throw

I forgot about the need to keep the method body to know what to inline for export: true. Here is how I think it would need to work. You add an exception to the library like MethodInlinedException. Given an inlined method like:

[Inline(InlineBehavior.Throw, export: true)]
public static bool Implies(this bool self, [InlineParameter] bool other)
{
	if (!self) return true;
	return other;
}

It would get rewritten to:

[Inline(InlineBehavior.Throw, export: true)]
public static bool Implies(this bool self, [InlineParameter] bool other)
{
	throw new MethodInlinedException();
	if (!self) return true;
	return other;
}

When inlining it into other projects via export: true, the inliner would know to skip the throw new MethodInlinedException(); portion since it was the special MethodInlinedException provided with the library and the InlineBehavior.Throw was applied.