Skip to content

Include 'new' in core scenarios for target-typed static name lookup, and editorial updates #9199

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions meetings/2025/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,7 @@ All schedule items must have a public issue or checked-in proposal that can be l
## Schedule when convenient

- [Readonly setter calls on non-variables](https://github.com/dotnet/csharplang/blob/main/proposals/readonly-setter-calls-on-non-variables.md) jnm2
- [Target-typed static member lookup](https://github.com/dotnet/csharplang/blob/main/proposals/target-typed-static-member-lookup.md) jnm2, CyrusNajmabadi
- Triage (working set)

## Recurring topics
Expand Down
46 changes: 24 additions & 22 deletions proposals/target-typed-static-member-lookup.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,8 @@

Champion issue: <https://github.com/dotnet/csharplang/issues/9138>

Thanks to those who provided insight and input into this proposal, especially @CyrusNajmabadi!

## Summary

This feature enables a type name to be omitted from static member access when it is the same as the target type.
Expand Down Expand Up @@ -170,7 +172,7 @@ void M(string p) => ...

### Target-typing with invocations

A core scenario for this proposal is calling factory methods, providing symmetry between production and consumption of values.
A core scenario for this proposal is calling factory methods. This enables the use of the feature with some of today's class and struct types. This also provides symmetry between production and consumption of values at a future point when there is a facility for `is .Some(42)` to light up without a type hierarchy, which is a future potential with discriminated unions.

```cs
SomeResult = .Error("Message");
Expand All @@ -183,6 +185,27 @@ For an invocation expression such as `e(...)` where the invoked expression `e` i

Even though the conversion always succeeds when the invoked expression `e` is a _target-typed member binding expression_, further errors may occur if the invocation expression cannot be bound for any of the same reasons as though the _target-typed member binding expression_ was a non-target-typed expression, qualified as a member of `T`. For instance, the member might not be invocable, or might return a type other than `T`.

### Target-typing after the `new` keyword

A core scenario for this proposal is enable the `new` operator to look up nested derived types. This provides symmetry between production and consumption of values with class DUs and with today's type hierarchies based on nested derived classes or records.

```cs
new .Case1(arg1, arg2)
```

This balances the consumption syntax:

```cs
du switch
{
.Case1(var arg1, var arg2) => ...
}
```

This would continue to be target-typed static member access (since nested types are members of their containing type), which is distinct from target-typed `new` since a definite type is provided to the `new` operator.

TODO: spec the conversion
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are other todos in this file. I'm happy merging as-is, since it doesn't seem like there will be an issue in principle coming up with the conversion, and the proposal is being discussed at a higher level currently.


### Notes

As with target-typed `new`, targeting a nullable value type should access members on the inner value type:
Expand Down Expand Up @@ -282,27 +305,6 @@ with (expr)

This doesn't seem to be a popular request among the language team members who have commented on it. If we go ahead with the proposed target-typing for `.Name` syntax, this seals the fate of the requested `with` statement syntax shown here.

## Expansions

To match the production and consumption sides even better, it could be very desirable to enable the `new` operator to look up nested derived types in the same way:

```cs
new .Case1(arg1, arg2)
```

This would continue to be target-typed static member access (since nested types are members of their containing type), which is distinct from target-typed `new` since a definite type is provided to the `new` operator.

If target-typed static member access is not allowed in this location, the downside is that the production and consumption syntaxes will not have parity.

```cs
du switch
{
.Case1(var arg1, var arg2) => ...
}
```

In cases where the union name is long, perhaps `SomeDiscriminatedUnion<ImmutableArray<int>>`, this will really stand out.

## Alternatives

### Alternative: doing nothing
Expand Down