How to convert this from VB.Net to C#? (lambdas)

[Furty]

This compiles in VB.Net:

Protected Shared Function CombineFunc(Of T)(ByVal d1 As Func(Of T, Boolean), _
ByVal condType As Compare, _
ByVal d2 As Func(Of T, Boolean)) As Func(Of T, Boolean)

        'Return a delegate which combines delegates d1 and d2
        Select Case condType
            Case Compare.Or : Return Function(x) d1(x) Or d2(x)
            Case Compare.And : Return Function(x) d1(x) And d2(x)
            Case Compare.Xor : Return Function(x) d1(x) Xor d2(x)
            Case Compare.Equal : Return Function(x) d1(x) = d2(x)
            Case Compare.OrElse : Return Function(x) d1(x) OrElse d2(x)
            Case Compare.AndAlso : Return Function(x) d1(x) AndAlso d2(x)
            Case Compare.NotEqual : Return Function(x) d1(x) <> d2(x)
            Case Compare.LessThan : Return Function(x) d1(x) < d2(x)
            Case Compare.GreaterThan : Return Function(x) d1(x) > d2(x)
            Case Compare.LessThanOrEqual : Return Function(x) d1(x) <= d2(x)
            Case Compare.GreaterThanOrEqual : Return Function(x) d1(x) >= d2(x)
            Case Else
                Throw New ArgumentException("Not a valid Condition Type", "condType")
        End Select
    End Function

But my conversion to C# does not:

protected static Func<T, bool> CombineFunc<T>(Func<T, bool> d1, Compare condType, Func<T, bool> d2)
{
//Return a delegate which combines delegates d1 and d2
switch (condType)
{

                case Compare.Or:
                    return (x) => d1(x) | d2(x);
                case Compare.And:
                    return (x) => d1(x) & d2(x);
                case Compare.Xor:
                    return (x) => d1(x) ^ d2(x);
                case Compare.Equal:
                    return (x) => d1(x) == d2(x);
                case Compare.OrElse:
                    return (x) => d1(x) || d2(x);
                case Compare.AndAlso:
                    return (x) => d1(x) && d2(x);
                case Compare.NotEqual:
                    return (x) => d1(x) != d2(x);
                case Compare.LessThan:
                    return (x) => d1(x) < d

[Judah Gabriel Himango]

Wow. Another VB abomination. If I were to guess at what this is doing, I'd guess that it's doing a dynamic comparison -- e.g. at runtime, it would see if the return type (always bool?) can be compared? Hmm. An alternative theory is that it should be Func<bool,T>, not Func<T, bool>. That is, it returns T, which might work for such comparisons at runtime. Compiling your code there and looking it up in reflector doesn't help much. Looks like the VB compiler creates some lambda classes under the hood and uses those for comparison. Can't quite figure out what it's doing exactly.

Tech, life, family, faith: Give me a visit. The apostle Paul, modernly speaking: Epistles of Paul Judah Himango

[Furty]

Judah Himango wrote:

An alternative theory is that it should be Func<bool,t>, not Func<t,>. That is, it returns T, which might work for such comparisons at runtime.

Only some of course, so that still wouldn't explain it :~ Still lost on this one. What I've done for now is ditch the method you see here all togeher and the "Compare" enum associated with it, and have replaced it with code that makes sense (well, to a C# guy) and compiles. I'd still love to find out whether the above example is just me missing the point on the conversion to c#, or whether it's an anomoly that allows really, really shaky VB code to compile.

[Judah Gabriel Himango]

Furty wrote:

Only some of course, so that still wouldn't explain it

Right, and maybe the VB compiler is doing run-time resolution of that type ala duck typing. These are all just guesses, though, as I'm a pure-blooded C# man myself. :-D

Tech, life, family, faith: Give me a visit. The apostle Paul, modernly speaking: Epistles of Paul Judah Himango

[Gideon Engelberth]

I wouldn't call it run-time resolution, but it seems that the actual data used for True and False are just integers 1 and 0, and the code compiles to an integer comparison. This will end up giving the same result as calling Boolean.CompareTo(Boolean). Seeing as none of the integral data types seem to have operators defined that I can see, I don't see any reason why the C# compiler should prevent you from using those expressions.