# 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](https://github.com/dotnet/csharplang/blob/master/proposals/low-level-struct-improvements.md).
[Previously](LDM-2020-09-23.md), 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.

