Proposal discussion: Target-typed static member lookup

[jnm2]

Specification: proposals/target-typed-static-member-lookup.md
Champion issue: #9138

Summary

This feature enables a type name to be omitted from static member access when it is the same as the target type.

This reduces construction and consumption verbosity for factory methods, nested derived types, enum values, constants, singletons, and other static members. In doing so, the way is also paved for discriminated unions to benefit from the same concise construction and consumption syntaxes.

type.GetMethod("Name", .Public | .Instance | .DeclaredOnly); // BindingFlags.Public | ...

control.ForeColor = .Red;          // Color.Red
entity.InvoiceDate = .Today;       // DateTime.Today
ReadJsonDocument(.Parse(stream));  // JsonDocument.Parse

// Production (static members on Option<int>)
Option<int> option = condition ? .None : .Some(42);

// Production (nested derived types)
CustomResult result = condition ? new .Success(42) : new .Error("message");

// Consumption (nested derived types)
return result switch
{
    .Success(var val) => val,
    .Error => defaultVal,
};

[colejohnson66]

I'm personally not a fan of the "dot" syntax. I'd much prefer _.Member.

[jnm2]

Now, if we could get a hat trick with type argument inference as well I'd be a very happy camper.

List<var> x = GetList(); or List<_> x = GetList(); have been discussed in LDM. That would have a nice synergy here.

[AndersKehlet]

In forty years a C# program will just be _

The intent of the programmer is inferred.

[HaloFour]

Unless _ is an identifier in scope, then the compiler will simply collapse into a blackhole. :)

[yaakov-h]

finally the compiler becomes the void

[huoyaoyuan]

#auto<auto>
auto auto;

auto auto(auto)
{
    auto::auto<<auto;
    auto auto;
}

[ljfio]

Overall, this doesn't promote readability and quick comprehension of what the code is doing.

However, if this does become a language feature I think this should be restricted to Enum types.

Also, why bother with the . at all in that case?
Current langauge features already delivers some of this with static using statements...

using static System.Drawing.Color;
control.ForeColor = Red;

[jnm2]

These points are addressed in the linked draft.

[CyrusNajmabadi]

The proposal covers these questions.

Also, why bother with the . at all in that case?

Specifically, because we view it as a good thing that we're not overloading a simple identifier. In that form, it can be not at all clear if htis is referencing something already in scope, as opposed to specifically finding values in an entirely different scope.

Current langauge features already delivers some of this with static using statements...

And it is not used or convenient. We've searched for just that.

However, if this does become a language feature I think this should be restricted to Enum types.

This limits many use cases that would be very nice to have that teh proposal covers.

[ljfio]

It's going to be hard to objectively tell us that the code is more readable considering it's hiding information about the type.

I take on board the comments relating to the reason behind introducing this but subjectively this isn't for me.

If there is a way to make this optional or disallow using it in projects, please make this a possibility.

[jnm2]

If there is a way to make this optional or disallow using it in projects, please make this a possibility.

All new language features are optional by default. Disallowing due to style concerns is what analyzers are perfect for.

[iam3yal]

Initially I disliked it as well but I think I can get used to it pretty easily. :D

[Richiban]

Great proposal @jnm2; when this was originally discussed I never wanted the leading dot but I think your explanation in the proposal has won me over, especially if the feature's going to be applicable to any static member with the correct type.

[koszeggy]

Option<int> option = condition ? .None : .Some(42);

Isn't it a problem that condition?.None is already a valid syntax today? I know that omitting the dot or using _.Identifier have other potential clashes; still, I prefer them to the bare dot-prefix syntax. Dunno, maybe just because this one and the fluent syntax look too much alike, which creates confusion and makes the code less readable, at least for me.

[jnm2]

I lean towards leaving this choice in users' hands. Users who think this is ambiguous even with the spacing can use (.None). But remember, sometimes this is starting on a new line, and forbidding that seems heavy-handed.

The compiler can work it out by looking ahead for : just like it does for collection expressions after ?.

[huoyaoyuan]

The ternary operator has already caused parsing difficulties in cases like ?() or ?[]. Can this be solved by adjusting how it's parsed?

[CyrusNajmabadi]

Yes. This is a parsing area we understand how to solve.

[jnm2]

The specification is ready for LDM and committed at proposals/target-typed-static-member-lookup.md.

[julealgon]

@jnm2 Is this a new organization pattern you guys are doing from now on?

I assume this is due to the fact that discussions have threads capabilities whereas the issue is flat (so there is a substantial benefit on keeping the discussion here?).

[huoyaoyuan]

It was announced at #8596

[jnm2]

Yep, see https://github.com/dotnet/csharplang/blob/main/Design-Process.md#steps-to-move-a-discussion-to-a-champion-feature.

[jnm2]

Example of the feature using both unary and binary operators and both regular expressions and patterns:

foreach (var property in type.GetProperties(.Public | .NonPublic | .Static | .Instance | .DeclaredOnly))
{
    if (property.SetMethod is not { } setter)
    {
        continue;
    }

    if ((setter.Attributes & .MemberAccessMask) is not (.Public or .Family or .FamORAssem))
    {
        continue;
    }
    
    // ...
}

Instead of today's:

foreach (var property in type.GetProperties(
    BindingFlags.Public | BindingFlags.NonPublic
    | BindingFlags.Static | BindingFlags.Instance
    | BindingFlags.DeclaredOnly))
{
    if (property.SetMethod is not { } setter)
    {
        continue;
    }

    if ((setter.Attributes & MethodAttributes.MemberAccessMask) is not (
        MethodAttributes.Public or MethodAttributes.Family or MethodAttributes.FamORAssem))
    {
        continue;
    }
    
    // ...
}