csharplang/meetings/2020/LDM-2020-10-12.md

C# Language Design Meeting for October 12th, 2020

Agenda

1. General improvements to the struct experience (continued)

Quote of the Day

• "Only 5 people are going to use it..."
• "We said that about function pointers too."

C# Community Ambassadors

We have been taking a look at https://github.com/dotnet/csharplang/discussions/3878, which is around how to help community proposals into better shape to be looked at by LDM. We largely agree with the points raised, which is that most community issues are in a state that isn't quite good enough to be sponsored by an LDT member, but also not controversial or generally discouraged enough to be outright rejected. Our move to enabling discussions on the repo itself was the first step in this direction: discussions are more free-form, allow multiple branching conversations, and we view them as having less requirements towards creating one. The next step we're taking today is nominating a few community members to become ambassadors to the community: @jnm2, @YairHalberstadt, and @svick. This role will be focussed around helping triage incoming issues and discussions, helping community members get their proposals into a state that can realistically be looked at by LDT members and potentially championed, and helping with deduplication as it is noticed. We're starting very small with this experiment: if it proves successful, we can consider expanding the list to more members of the csharplang community, of which there are several deserving candidates. As part of this, we're tentatively hoping to review promising community proposals at a more regular cadence, hopefully monthly.

Community ambassadors are not members of the LDT and do not have the ability to champion issues. They will help us look at deserving community proposals, and we value their input, as we value the input of the general community here.

Discussion

Today, we finished going through the fixed fields proposal, found here. Previously, we made it through the Provide ref fields section of the specification. Today, we finished going through the rest. Again, most the conversation was dedicated to the specification itself, but there were a few points brought up that will be updated in the specification later:

• ThisRefEscapes is defined very narrowly in this proposal, not allowed on any virtual methods (including methods from interfaces). In our initial investigations, we don't see a huge need for allowing it on interface methods. We can consider this in the future if it ends up being a friction point, but will need a good amount of work around ensuring that OHI is correctly respected.
• We considered the issue of whether we should use syntax for ThisRefEscapes and DoesNotEscape, and nearly-unanimously decided on using attributes. Attributes allow us to have a more descriptive name that users are less likely to accidentally use. Further, all this attribute is controlling is a modreq, not the actual implementation of the method. We have existing attributes such as SpecialNameAttribute that control emit flags like this, so it's not unprecedented.
• The syntax for fixed buffer locals is actually quite generally attractive: it would be nice if we could remove the requirement for specifying fixed in fields. It would further simplify the language: we even have parser code that parses this form today so that we can give nicer errors to people coming from C/C++. It would further resolve an ambiguity: in the proposal today, old- style fixed-size buffers are differentiated from new-style by whether or not the field is in an unsafe context: by omitting the fixed, we have a completely different syntax that is unambiguous.
• We don't believe there is any real motivating scenario for either fixed multi-dimensional arrays or fixed jagged arrays of a specific inner length. Jagged arrays of this form would work: int[] array[10], where you have a fixed buffer of array references, but allocating the inner array as part of the containing structure itself isn't currently seen as an important scenario. Multidimensional arrays today need to call into CLR helper methods today and are generally slower. We can think about this later if a scenario comes up.
• We might want to make "inline array" a first-class type in the CLR. This would allow for things such as substituting in type parameters. This will largely be driven by the CLR design here.