with (…) { .Member = … } — Explicit Receiver Blocks Using Leading Dot Syntax

[doubledeej]

Proposal: Implicit Receiver Blocks Using Leading-Dot Syntax

(A Safe, Explicit, Unambiguous Alternative to Delphi's with)

Summary

As a former Delphi developer, I've really missed the 'with' capability of that language in C#. This proposal introduces a new statement form which avoids the ambiguity of previous concern in a potential C# implementation:

with (receiverExpression) {
    .Member = value;
    .OtherMember.Method();
}

Inside a with block, leading-dot expressions are treated as member accesses on the specified receiver, equivalent to:

receiverExpression.Member = value;
receiverExpression.OtherMember.Method();

This provides the ergonomic benefits of Delphi's with while avoiding all name-resolution ambiguity.
The feature integrates cleanly with C#'s existing semantics, requires minimal grammar additions, and preserves full refactoring and IDE tooling support.

---

Motivation

C# developers often write repetitive code when configuring or modifying an object:

person.Name = "Frank";
person.Age = 33;
person.Address.City = "Denver";

A block-based approach improves readability and visually groups related operations:

with (person) {
    .Name = "Frank";
    .Age = 33;
    .Address.City = "Denver";
}

Many languages include an "implicit receiver" or "context object" construct:

• Delphi's with
• Swift's with
• Kotlin's with / apply
• JavaScript's historical with

However, Delphi's and JavaScript's versions introduced ambiguity that made variable resolution unpredictable, requiring a full parsing of the code to determine the receiver.

This proposal introduces a safe version that avoids all historical pitfalls through explicit leading-dot notation.

Common real-world benefits include:

• DTO and POCO initialization
• UI element configuration
• Builder-pattern code
• Mapping and transformation logic
• Procedural setup blocks

---

Design Overview

Syntax

with (receiverExpression) {
    .Member = ...;
    .Method();
    .Nested.Property = ...;
}

Meaning

Inside the with block:

• A leading-dot expression is equivalent to receiver.Member.
• Name resolution for leading-dot forms does not consider locals, parameters, fields, or outer scopes.
• There is no shadowing or ambiguity.
• The receiver expression is evaluated once and stored in a compiler-generated temporary (similar to foreach and using).

Example desugaring:

with (person) {
    .Name = "Frank";
    .Age = 33;
}

Desugars to:

var __temp = person;
__temp.Name = "Frank";
__temp.Age = 33;

---

Binding Rules

1. Leading-dot (.Name) always binds to the receiver object.
2. The block's lexical scope is unchanged; regular names bind as usual.
3. IntelliSense lists members of the receiver.
4. Rename refactoring and Find All References behave as if explicit references were written.

---

Examples

Basic Usage

with (order) {
    .OrderId = 42;
    .IsPaid = true;
    .Customer.Name = "Alice";
}

UI Configuration

with (button) {
    .Text = "OK";
    .Enabled = true;
    .Style.Padding = new Thickness(4);
}

Builder Pattern

with (builder) {
    .Name("Frank");
    .Age(33);
    .Email("[email protected]");
}

Mapping Code

with (dto) {
    .FirstName = model.GivenName;
    .LastName = model.Surname;
    .IsActive = entity.Enabled;
}

---

Why This Version is Safe

Delphi's with was rejected by many languages because it made identifier resolution dependent on hidden context:

with Foo do
  Bar := 1; // is this Foo.Bar or a local Bar?

This proposal avoids those problems:

• A leading dot cannot refer to anything except the receiver.
• A non-leading-dot cannot accidentally resolve to the receiver.
• Name lookup remains deterministic.
• The receiver is explicitly stated in the with (...) header.

It preserves C#'s core principles of:

• Clear binding rules
• Strong toolability
• No hidden context
• No breaking changes

---

Grammar Sketch

with_statement
    : 'with' '(' expression ')' embedded_statement

implicit_member_access
    : '.' identifier type_argument_list? member_access_suffix*

The compiler treats implicit member accesses as equivalent to <receiver>.Member.

---

Interaction With Existing Features

Object Initializers (future extension)

var person = new Person {
    .Name = "Frank",
    .Age = 33
};

Nested with blocks

Inner blocks override the implicit receiver for leading-dot expressions.

Nullable Annotations

Leading-dot member access respects nullable analysis for the receiver expression.

LINQ

No conflicts; lambdas and query expressions are unaffected.

---

Alternatives Considered

• Local alias (var p = person;)
  Lacks grouping and does not reduce enough boilerplate.

• Lambda receivers (Configure(x => { x.Name = ... }))
  Verbose and adds unnecessary structural noise.

• Fluent APIs
  Require library design changes and do not address general member-assignment patterns.

• Target-typed expressions
  Not relevant to repeated member prefixes.

This proposal directly solves the repeated-prefix problem in a minimal way.

---

Drawbacks

• Introduces a new syntactic form (with (...) {}).
• Requires updates to Roslyn, syntax trees, and IDE tooling.
• May invite future discussion about extending the feature into object initializers.

No compatibility issues are expected.

---

Conclusion

This proposal adds a small but valuable ergonomic improvement to C#. It aligns with the language's design philosophy, avoids the pitfalls of historical with constructs, and meaningfully improves clarity and reduces noise in common real-world scenarios.

Leading-dot implicit receiver notation is:

• Safe
• Unambiguous
• Easy to teach
• Easy to implement
• Visually clear
• Fully compatible with existing C# code

It offers significant benefit for minimal cost and feels like a natural evolution of the language.

[HaloFour]

See: #1534