IObjectCreationExpression API shape

[mavasani]

    public interface IObjectCreationExpression : IHasArgumentsExpression
    {
        /// <summary>
        /// Constructor to be invoked on the created instance.
        /// </summary>
        IMethodSymbol Constructor { get; }
        /// <summary>
        /// Explicitly-specified member initializers.
        /// </summary>
        ImmutableArray<ISymbolInitializer> MemberInitializers { get; }
    }

The shady part is MemberInitializers, which only expose a part of the IOperation tree within the object member initializer.

Let me give an example:

Class F
    Public Field As Integer
End Class

Class C
    Public Sub M1()
        Dim x2 = New F() With {.Field = 2}
    End Sub
End Class

IOperation tree for object creation:

IOperation tree for "Dim x2 = New F() With {.Field = 2}"

IVariableDeclarationStatement (1 variables) (OperationKind.VariableDeclarationStatement)
  IVariableDeclaration: x2 As F (OperationKind.VariableDeclaration)
    Initializer: IObjectCreationExpression (Constructor: Sub F..ctor()) (OperationKind.ObjectCreationExpression, Type: F)
        Member Initializers: IFieldInitializer (Field: F.Field As System.Int32) (OperationKind.FieldInitializerInCreation)
            ILiteralExpression (Text: 2) (OperationKind.LiteralExpression, Type: System.Int32, Constant: 2)

IOperation tree for it's child node, object member initializer:

IOperation tree for "With {.Field = 2}"

IOperation (OperationKind.None)

IOperation tree for one of the child nodes of the member initializer, NamedFieldInitializerSyntax:

IOperation tree for ".Field = 2"

IAssignmentExpression (OperationKind.AssignmentExpression, Type: System.Int32)
  Left: IFieldReferenceExpression: F.Field As System.Int32 (OperationKind.FieldReferenceExpression, Type: System.Int32)
      Instance Receiver:  (OperationKind.None)
  Right: ILiteralExpression (Text: 2) (OperationKind.LiteralExpression, Type: System.Int32, Constant: 2)

I think we either need to change MemberInitializers to return the entire IOperation tree for each initializer (which would be the IAssignmentExpression for the field initializer) OR replace MemberInitializers with InitializerOpt of new OperationKind.ObjectMemberInitializer, which exposes all the initializer expressions.

[mavasani]

Design Team Decision:

1. Existing shape of IObjectCreationExpression is fine.
2. Ensure that we do not return IAssignmentExpression when asked for IOperation for NamedFieldInitializerSyntax, i.e. .Field = 2 - this should make the tree consistent

Open question: Do we need to still somehow ensure we expose IFieldReferenceExpression in the IOperation tree rooted at New F() With {.Field = 2}? Otherwise, analyzers analyzing IFieldReferenceExpression will not receive any callbacks when analyzing this code.

cc @AlekseyTs , @CyrusNajmabadi

[CyrusNajmabadi]

Do we need to still somehow ensure we expose IFieldReferenceExpression

That's an interesting question. Can you add it to the questions for the design meeting?

I see the benefit of it being in the tree. That way people can just register a single callback. One way we could do that would be to have IFieldInitializer point at the IFieldReferenceExpression instead of directly at the IFieldSymbol.

Note: IFieldInitializer really seems to be defined for the actual field case. i.e. "private int i = 0" or "dim i, j, as new whatever()". I'm not sure i like that it is being used in the "new with" expression.

[jinujoseph]

Design Team Decision:

NamedFieldInitializerSyntax, i.e. .Field = 2 we will return IAssignmentExpression that is Initializers for IObjectCreationExpression will be all IOperations instead of ISymbolInitializers

We should probably have something like IObjectInitializer, which can contain several of these assignments and their invocations (add with arguments), For now we can say it's an array of IOperation.

• Check if it will work for nested Initialization.
• Check if it makes sense to make a special node instead of collection Initializer.

[jinujoseph]

blocked design decision on #18781