Create spec for lambda params with modifiers without type name

[Rekkonnect]

Creates a spec for #338

This permits the simplified declaration of lambdas with parameters with modifiers, by omitting their type name.

[CyrusNajmabadi]

Can you add a line saying this is only for parenthesized lambdas?

[CyrusNajmabadi]

Speclet lgtm. @333fred for another pair of eyes.

[Rekkonnect]

An edge case includes the addition of the scoped modifier in C# 11. Currently, lambda parameters accept the scoped modifier, therefore those could also be affected from this spec. We want to decide whether those are being supported or not.

[Rekkonnect]

Also, in preview, params in lambda parameters is being supported. We also need to consider this case.

[333fred]

A few small comments, overall this is looking good.

[333fred]

@CyrusNajmabadi this looks good enough to go to LDM to me. Want to add it to "schedule when convenient"?

[CyrusNajmabadi]

@333fred I was going to check with @MadsTorgersen @KathleenDollard first when teh right time was to bring things since we're so heads down in 12 right now. Basically, i'd bring this the next time we're open to looking for the next batch of championed constructs to take :)

[333fred]

I believe that's what "schedule when convenient" there for 😉.

[CyrusNajmabadi]

Ah, i thought those were for meetings where we didn't have anything pressing, but we were still prior to the point that we were trying to decide on new features :)

[Rekkonnect]

As for scoped parameters, since scoped is contextual, the compiler currently attempts to parse that as a type. Perhaps we will not make a move to support (scoped x) to infer the type of x and granting it the scoped modifier.

[Rekkonnect]

As for scoped parameters, since scoped is contextual, the compiler currently attempts to parse that as a type. Perhaps we will not make a move to support (scoped x) to infer the type of x and granting it the scoped modifier.

As per the list of breaking changes for C# 11, scoped no longer refers to a type name, therefore this restriction should not take place. scoped can be safely evaluated as a modifier in an implicit type lambda parameter list.

Therefore:

private delegate int D(scoped int x, scoped int y);
D d = (scoped x, scoped y) => x + y;

is valid and scoped reflects the modifier, not a type named scoped.

Will update the spec accordingly to reflect this change, citing the above reference.

[jjonescz]

scoped no longer refers to a type name

Is that right? Seems the breaking change only disallows declaring new types named scoped, but you could reference an existing type named scoped from a DLL and then this would be a break (not saying the break wouldn't be acceptable):

var d = (scoped x, scoped y) => x + y;

[Rekkonnect]

The example:

ref scoped local; // Error

Hints that all available types named scoped are now inaccessible. And that behavior sounds very sane to me, since the type is no longer being explicitly available in other contexts, it would not be reasonable to enable accessing them in implicit lambda parameters.

[jjonescz]

ref scoped local; // Error

Maybe that's an error only when there's ref.

Hints that all available types named scoped are now inaccessible.

This test succeeds for me:

[Fact]
public void Scoped()
{
    var source1 = """
        public class scoped { }
        """;

    CreateCompilation(source1).VerifyDiagnostics(
        // (1,14): error CS9062: Types and aliases cannot be named 'scoped'.
        // public class scoped { }
        Diagnostic(ErrorCode.ERR_ScopedTypeNameDisallowed, "scoped").WithLocation(1, 14));

    var comp1 = CreateCompilation(source1, parseOptions: TestOptions.Regular10).VerifyDiagnostics(
        // (1,14): warning CS8981: The type name 'scoped' only contains lower-cased ascii characters. Such names may become reserved for the language.
        // public class scoped { }
        Diagnostic(ErrorCode.WRN_LowerCaseTypeName, "scoped").WithArguments("scoped").WithLocation(1, 14));
    var comp1Ref = comp1.EmitToImageReference();

    var source2 = """
        var d = (scoped x) => System.Console.WriteLine(x);
        d(new scoped());
        """;
    CompileAndVerify(source2, new[] { comp1Ref }, expectedOutput: "scoped").VerifyDiagnostics();
}

[Rekkonnect]

Nice observation, with a little bit more testing, even the listed breaking change does not currently apply:
SharpLab link

Note that the above uses the Default branch which is C# 11 based on the fact that the error about naming a type scoped exists.

This is either an undocumented decision, or an omission in the feature. We need a definite answer to how we're going to support scoped in implicit lambda parameter lists.

[CyrusNajmabadi]

if we're going to support ref and the like without an explicit type, then we need to support scoped in the same fashoin.

[Rekkonnect]

Do we want to introduce a breaking change in the following example:

public class C
{
    public void M(scoped sc, scoped scoped scsc)
    {
        MSc mSc = M;
        MSc mSc1 = (scoped sc, scoped scoped scsc) => { };
    }
    
    public delegate void MSc(scoped sc, scoped scoped scsc);
}

public ref struct @scoped { }

I really hate how this types out anyway and I believe it would be best to introduce the breaking change by requiring the @ in the @scoped type.

[CyrusNajmabadi]

I would put it as a case to consider and allow the ldm to make a determination on if it's ok or not.

Personally, I would take the break.

[Rekkonnect]

Digging through the issues, I also discovered that #6149 is touching the subject of scoped, perhaps it would be helpful to mention it here for future reference once the spec is settled.

[CyrusNajmabadi]

Suggested change

	For example,
	For example, these would not be legal.

Also, just do like the first 3 examples.

[Rekkonnect]

I think this note should also be removed