空传播算子和扩展方法

Question

I've been looking at Visual Studio 14 CTP along with C# 6.0 and playing with the null-propagation operator.

However, I couldn't find why the following code does not compile. The features are not yet documented so I'm not sure whether this is a bug or extension methods simply are not supported with the ?. operator and the error message is misleading.

class C
{
    public object Get()
    {
        return null;
    }
}

class CC
{
}

static class CCExtensions
{
    public static object Get(this CC c)
    {
        return null;
    }
}

class Program
{
    static void Main(string[] args)
    {
        C c = null;
        var cr = c?.Get();   //this compiles (Get is instance method)

        CC cc = null;
        var ccr = cc?.Get(); //this doesn't compile

        Console.ReadLine();
    }
}

Error message is:

'ConsoleApplication1.CC' does not contain a definition for 'Get' and no extension method 'Get' accepting a first argument of type 'ConsoleApplication1.CC' could be found (are you missing a using directive or an assembly reference?)

Answer 1

Yes. This is a bug. Thanks for bringing this up. The sample is supposed to compile and should result in a conditional invocation of Get regardless if Get is an extension or not.

Usage of "?." in cc?.Get() is an indication that caller wants cc null-checked before proceeding further. Even if Get could handle null somehow, caller does not want that to happen.

Answer 2

I don't work on the Roslyn team, but I am fairly confident that this is a bug. I took a look at the source code and I can explain what's happening.

First off, I disagree with SLaks answer that this isn't supported because extension methods do not dereference their this parameter. It is an unfounded claim, considering that there's no mention of it in any of the design discussions . Plus, the semantics of the operator turn into somethat that roughly looks like the ternary operator ( (obj == null) ? null : obj.Member ), so there's not really a good reason why it couldn't be supported in a technical sense. I mean, when it boils down to generated code, there really is no difference in the implicit this on an instance method and the explicit this on the static extension method.

The error message is a good clue that this is a bug, because it's complaining that the method doesn't exist, when it actually does. You may have tested this by removing the conditional operator from the call, using the member access operator instead, and having the code compile successfully. If this were an illegal use of the operator, you would get a message similar to this: error CS0023: Operator '.' cannot be applied to operand of type '<type>' error CS0023: Operator '.' cannot be applied to operand of type '<type>' .

The bug is that when the Binder is trying to bind the syntax to the compiled symbols, it uses a method private static NameSyntax GetNameSyntax(CSharpSyntaxNode, out string) [link] which is failing to return the method name that is needed when it tries to bind the invocation expression (our method call).

A possible fix is to add an extra case statement to the switch in GetNameSyntax [link] as follows (File: Compilers/CSharp/Source/Binder/Binder_Expressions.cs:2748 ):

// ...
case SyntaxKind.MemberBindingExpression:
     return ((MemberBindingExpressionSyntax)syntax).Name;
// ...

This was probably overlooked because the syntax for calling extension methods as members, that is using the member access operator) winds up using a different set of syntax than when used with the member access operator vs. the conditional access operator, specifically, the ?. operator uses a MemberBindingExpressionSyntax that wasn't taken into account for that GetNameSyntax method.

Interestingly, the method name is not populated for the first var cr = c?.Get(); which compiles. It works, however, because local method group members are first found for the type and are passed to the call of BindInvocationExpression [ link ]. When the method is being resolved (note the call to ResolveDefaultMethodGroup [ link ] before trying to BindExtensionMethod [ link ]), it first checks those methods and finds it. In the case of the extension method, it tries to find an extension method that matches the method name that was passed into the method, which in this case was an empty string instead of Get , and causes the erroneous error to be displayed.

With my local version of Roslyn with my bug fix, I get a compiled assembly whose code looks like (regenerated using dotPeek):

internal class Program
{
    private static void Main(string[] args)
    {
        C c1 = (C) null;
        object obj1 = c1 != null ? c1.Get() : (object) null;
        CC c2 = (CC) null;
        object obj2 = c2 != null ? CCExtensions.Get(c2) : (object) null;
        Console.ReadLine();
    }
}

Answer 3

The point of the null-propagation operator is to avoid derefencing a null value.

However, extension methods do not deference their this parameter, and in fact can be called perfectly fine on null values.
(although the method itself is likely to throw an exception if it doesn't expect null )

Therefore, it would be unclear whether a null-safe extension method call would skip the call or not.