Skip to content

Latest commit

 

History

History
59 lines (37 loc) · 3.79 KB

LDM-2024-10-16.md

File metadata and controls

59 lines (37 loc) · 3.79 KB

C# Language Design Meeting for October 16th, 2024

Agenda

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 for bringing more controversy. It was too easy, we needed something to rile people up."

Discussion

Simple lambda parameters

Champion issue: #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: #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: #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.