Member Access Block

[ActivistInvestor]

Proposal: Member Access Block

Summary

This proposal introduces a new syntactic feature for C#, called the Member Access Block, inspired by Visual Basic’s With...End With construct. It allows a concise and expressive way to perform multiple member accesses—assignments, method calls, nested property access—on a single object.

The proposal also includes a suggested disambiguating syntax using the member access operator (.) followed by a block, i.e., expr . { ... }, to avoid parsing conflicts and make the intent clearer.

Motivation

C# object initializers are a useful shorthand for property assignment but are currently limited to assignments after a constructor call. Furthermore, they prohibit method calls and deeper member access, which makes them ill-suited as a general-purpose syntax.

This proposal generalizes and expands the object initializer syntax into a more flexible Member Access Block that:

• Can be used with any expression that evaluates to a reference type.
• Allows not only property/field assignments, but also method calls and nested member access.
• Makes code more readable and concise by eliminating repeated object references.
• Introduces a syntax that avoids conflicts with existing grammar and semantics.

Example

Before

var person = Person.Create();
person.FirstName = "John";
person.LastName = "Doe";
person.Reset();
person.Address.City = "New York";

After (Using Member Access Block with . Syntax)

var person = Person.Create(). {
    FirstName = "John",
    LastName = "Doe",
    Reset(),
    Address.City = "New York"
};

or:

person. {
    FirstName = "John",
    LastName = "Doe",
    Reset(),
    Address.City = "New York"
};

Semantics and Design

Expression Target

Any valid expression that evaluates to a reference type may be used on the left-hand side of a Member Access Block:

GetPerson(). {
    FirstName = "Alice",
    Reset()
};

• The result of the expression must not be null at runtime.
• The block applies to the result of the expression and evaluates to the same object.

Allowed Member Access Forms

• ✅ Property and field assignments
• ✅ Method calls
• ✅ Deep/nested member access
• ✅ Event subscription (+=) and unsubscription (-=)
• ✅ Indexer usage

This removes the limitation imposed by compiler error CS0747, which in standard C# prohibits method calls inside object initializers.

Return Value

The block itself returns the result of the expression it is applied to, making it composable:

return GetPerson(). {
    FirstName = "Yvonne",
    LastName = "Smith",
    Validate()
};

Syntax Rationale

The inclusion of the . (member access operator) before the block disambiguates this syntax from object initializers or collection initializers. It visually and semantically suggests that the block contains member interactions, making it more intuitive and compiler-friendly.

Grammar Sketch

member-access-block ::= expression '.' '{' member-access-list '}'
member-access-list  ::= member-access (',' member-access)*
member-access       ::= property-assignment | method-invocation | event-subscription | nested-access

Comparison with Visual Basic With...End With

Feature	C# Object Initializers	VB With...End With	Proposed Member Access Block
Property assignments	✅ Yes	✅ Yes	✅ Yes
Method calls	❌ No (CS0747)	✅ Yes	✅ Yes
Nested member access	❌ No	✅ Yes	✅ Yes
Works with non-new expressions	❌ No	✅ Yes	✅ Yes
Returns the object	✅ Yes (new only)	❌ No	✅ Yes

Fluent API Comparison

var person = Person.Create()
    .WithFirstName("John")
    .WithLastName("Doe")
    .Reset();

vs.

var person = Person.Create(). {
    FirstName = "John",
    LastName = "Doe",
    Reset()
};

Feature	Fluent API	Member Access Block
Requires extra methods	✅ Yes	❌ No
Works with readonly props	✅ Yes (new object)	⚠️ Only if setter is available
Verbosity	🟡 Moderate	✅ Concise
Reuse of object reference	❌ No	✅ Yes

Potential Drawbacks

• Introduces new syntax that could have edge-case parsing considerations.
• May be unfamiliar to developers not used to VB-style constructs.
• Tooling and analyzers need updates to support the block form.
• Ambiguity might still arise in rare cases without clear grammar enforcement.

Conclusion

The Member Access Block, particularly when introduced with a disambiguating dot (.) before the block, offers an elegant and powerful shorthand for multiple member operations on the same object. It improves expressiveness, reduces redundancy, and provides a clear conceptual parallel to Visual Basic’s With...End With.

Future Considerations

• Allow use with value types (careful with copies).
• Allow the with keyword for readability: with obj { ... }
• Support scoped blocks as statements without needing a return value.

[HaloFour]

See: #6602

[ActivistInvestor]

#6602 proposes the syntax for factory methods, which this proposal gives an example of, but this proposal goes beyond use with factory methods, and proposes it be more generalized and functionally-equivalent to Visual Basic's With...End With.

[HaloFour]

Both entail expanding where initializer syntax may be used. Even if it warrants a separate discussion regarding the particular use cases the proposals are still related.

[ActivistInvestor]

It sure does warrant a separate discussion, as the proposals are not as related as they may at first seem, mostly because of my failure to flesh out more details, such as whether to enforce CS0747. IOW, should MemberExpr be limited to member assignment expressions (as they currently are), or should any member access expression be permitted.

The intent aims to achieve functional equivalence to VB's With...EndWith, that allows more than just member assignment, but rather any expression that involves a member access (instance method calls; event assignments; etc.).

Since it would appear to be little more than compiler candy, it doesn't seem that far-fetched to have the compiler rewrite a 'member access block' with the equivalent code that compiles today.

I will revise the proposal to target an equivalent to With...EndWith, that is usable anywhere and without the restrictions imposed on object initializers. I'll also propose a modification to the syntax to:

TargetExpr . {MemberAccessExpr, ...}

Using the member access operator to disambiguate a 'member access block' from an object initializer, since I doubt that the latter can be changed to support any type of member access expression allowed in the proposed member access block, making this proposal unrelated to #6602