# C# Language Design Meeting for October 16th, 2024

## Agenda

- [Simple lambda parameters](#simple-lambda-parameters)
- [Unbound generic types in `nameof`](#unbound-generic-types-in-nameof)
- [`typeof` string constants](#typeof-string-constants)

## Quote(s) of the Day

- "Wacky Generics is the name of my new band focused on kids music."
- "Today is apparently an 'everyone is in violent agreement' day." "And let me tell you how this solves extensions"
- "Thanks <redacted> for bringing more controversy. It was too easy, we needed something to rile people up."

## Discussion

### Simple lambda parameters

Champion issue: https://github.com/dotnet/csharplang/issues/338  
Questions: https://github.com/dotnet/csharplang/blob/53a58b04790ab20fadb7214827de3a91fe828121/proposals/simple-lambda-parameters-with-modifiers.md#open-ldm-questions

We started today by looking at a simple proposal that we've previously approved and trying to answer a few open questions that came up during implementation.

For the first question, on types named `scoped`, we're ok with breaking that in simple lambda parameters. We've previously done that in cases like `record` and `required`, and it makes
sense to do so here as well. We also don't think the case is pathological, like `field`, and we already warn on types named with all lowercase characters anyway.

For the second question, we're fine with accepting the recommendation of the implementation. The previous support for attributes on simple lambda parameters was intentional, and it would
be weird to end up in another location where we'd fall off the cliff to full parameters, rather than fixing that too.

#### Conclusion

Both recommendations are accepted; we will now interpret `scoped` as a modifier for simple lambda parameters, not a type name, and we will allow attributes on simple lambda parameters.

### Unbound generic types in `nameof`

Champion issue: https://github.com/dotnet/csharplang/issues/8480

We went through this new proposal. We're generally fine with it, but the implementation hasn't been rigorously reviewed yet. Given that, we're not 100% certain that all the semantic dark
corners that were previously mentioned have been fully solved. We're fine with the spec as is if a rigorous review finds that it satisfies all of these corners, but if it doesn't, then we
approve a more limited form in principle, where we cut off those dark corners and simply make them an error for our future selves to solve.

#### Conclusion

Approved in principle. If the implementation proves to be much more challenging than it currently appears, we will make those more challenging locations an error.

### `typeof` string constants

Champion issue: https://github.com/dotnet/csharplang/issues/8505

Finally today, we did a bit of triage, and looked at this proposal on allowing a limited constant expression form for the fully qualified metadata name string. One immediate concern we have
is that the format here is not documented; in fact, some constrained environments in the past have actually stripped out reflection APIs entirely. We're also not particularly sure about
the scenarios that would require this to be a constant; attributes, for example, could just take a `Type` instead, rather than needing to take the full name of the type. That is far more
robust, as it's an assembly-qualified name that then causes the runtime to probe for that exact type, while a string that lacks assembly qualification is ambiguous. Instead, we think that
an easy option here is a source generator where the user puts a `[GenerateTypeName<MyType>()]` attribute on a class, and a source generator fills in a partial part with a constant string
representing the full type name. We're not unsympathetic to more general constant evaluation in C#, but this is too narrow of a usecase to drive it.

#### Conclusion

Rejected.
