# C# Language Design Meeting for April 8th, 2026

## Agenda

- [Target-typed static member access](#target-typed-static-member-access)
    - [Scope review and motivating examples](#scope-review-and-motivating-examples)
    - [Dot or no dot](#dot-or-no-dot)
    - [Initial rollout scope](#initial-rollout-scope)

## Quote(s) of the Day

- "The fact that Rust proposes a dot is not a huge vote in favor of C# as they actually use `::` as the separator. Our
  equivalent would be using `::Name` instead." "That's like four dots" "Goes well with our history, since `#` is like 4 `+`s"

## Discussion

### Target-typed static member access

Champion issue: https://github.com/dotnet/csharplang/issues/9138  
Spec: https://github.com/dotnet/csharplang/blob/c2465a0605180e9624ee5ea9d6e0eab7e93a7c5b/proposals/target-typed-static-member-access.md

Continuing from our [previous discussion](./LDM-2026-03-11.md#target-typed-static-member-access), we returned to
the proposal to decide on its initial scope and settle the main open syntax question.

#### Scope review and motivating examples

We began by revisiting the separable pieces of the proposal and walking through concrete examples from real code.
These covered the basic `.Member` form, use in patterns, flag combinations such as `.Public | .Static |
.DeclaredOnly`, factory-style invocations such as `.Some(42)`, and `new .NestedType(...)` for nested derived types.

This review reinforced that the proposal's value is in removing repeated type names where the target type is already
clear. Enums, constants, flags, and generic or declarative code remain the most compelling motivation, especially in
examples where the fully-qualified spelling is repetitive enough to obscure the actual intent of the code.

We also reaffirmed that the proposal is best thought of as a local, point-of-use shorthand. That locality matters:
we want to reduce redundancy without broadly importing names into scope or changing how nearby code binds in unrelated
contexts.

#### Dot or no dot

The main decision point for today was syntax. We compared the proposal as written, where target-typed static member
access always uses a leading `.`, against several alternatives: omitting the dot entirely, making the dot optional as
a disambiguator, or using a different sigil such as `_.Member`.

The strongest argument in favor of the leading dot was clarity. The dotted form stands out as a target-typed
construct, much like `new()` and collection expressions already do. Without the dot, a simple identifier could just
as easily be read as a local, a member already in scope, something imported through `using static`, or a target-typed
member access. That ambiguity would make the feature both harder to read and harder to reason about.

We spent some time on whether `using static` is already a sufficient escape hatch. We do not think it is. `using
static` affects an entire scope and brings many names into lookup whether or not they are needed, while this proposal
is attractive precisely because it stays narrow and explicit at the point where the shorthand is used.

There was still some sympathy for the no-dot approach in the abstract, particularly if we were imagining a new
language from scratch. Optional dot also had support as a possible disambiguation mechanism. However, we did not
like optionality as the main direction: if the feature frequently needs marking for clarity, then it should be
marked consistently; if ambiguities are rare, spelling out the full type name in those rare cases is an acceptable
fallback. The underscore-based alternative also felt noisy and in tension with `_`'s existing meaning.

#### Conclusion

We will move forward with the proposed syntax. Target-typed static member access will always use the leading `.`.

#### Initial rollout scope

With the syntax question settled, we used the remaining time to get a quick read on the current scope. There was
strong support for continuing with the core feature set: the basic expression form, pattern matching, operator-based
scenarios, and factory-style invocations.

The area that still drew the most hesitation was target-typing after the `new` keyword for nested types. That piece
did not feel as central as the enum, constant, and factory scenarios, and several of us wanted more time to think
through its ergonomics before folding it into the initial version.

#### Conclusion

We will continue with the core proposal using dotted syntax, and will revisit target-typing after `new` in a future
meeting.
