meetings/2020/LDM-2020-10-12.md
struct experience (continued)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.
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.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.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.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.