- "If only there was a way that could be the quote of the day without incriminating someone." "I'm trying to make my jokes unquotable."
We started today by going through the partial properties proposal in detail, and trying to address the open questions in the proposal. As part of the motivation, we took a quick look at how popular the field-based approach to property generation is: CommunityToolkit.Mvvm, which added an INPC generator based on fields in version 8.0.0, has over 159,000 downloads as of these notes, 50,000 more than the previous major version of the library. They've also started using diagnostic suppressors to allow property-based attributes to be put on fields, suppressing the warnings about incorrect attribute targets and copying those attributes over to the implementation of the property. We don't think this is great: it's working around the language, rather than with the language, and we'd like to address it.
We considered whether we should support implementations being full auto-properties. There are some uses case for this: for example, the regex generator might want
to be able to say public Regex Prop { get; } = ...; in the generated file. And, language-wise, the issues with allowing this are fairly minimal. However, we think
that there's a decent number of tooling and experience issues with it, as the tooling will need to pick a version to consider the declaration, and no matter what we
do it will likely feel arbitrary. With semi-auto properties the workaround is not hard either: it's just public Regex Prop { get => field; } = ...;. Given this,
we'll stick with the restriction that the implementation part cannot be a fully auto-property.
We looked at the open question on expanding the feature to cover indexers. We think this is a reasonable expansion: it raises no new questions, has fairly minimal
impacts on the implementation, and keeps the language regular. It does mean that we have only one non-field member type that can't be partial now: events. We
think extending the feature to events goes a bit farther than we'd like for now. We've had no requests for the expansion, and adding it would bring a number of new
questions on field-like events, what to allow/disallow, and others that we're not ready to answer at this time.
Finally, we think that while we're doing partial properties, there is opportunity to clean up some partial papercuts, such as modifier ordering. We will make
a list of these papercuts and bring them to a future LDM for consideration.
Feature is approved as specified, indexers will be included.
Finally today, we have a question that arose from implementation, around whether lambda default parameters can affect the existence of a conversion. We're a bit
concerned by the behavior as specified, as it means that changing a parameter default value will have an impact on overload resolution. We're not OK with this
impact, and want to revise the rules here to avoid that. After some discussion, we came to the conclusion that the conversion from lambda to delegate type should
always exist, regardless of params/default parameter value differences. We then considered whether those differences should cause a warning or an error later in
the pipeline, after overload resolution. We're mostly in favor of a warning here, as the code the code is unambiguous in meaning, if not anything we expect to be
written outside of compiler unit tests. We also think that, for method group conversions, we should not warn at all.
The existence of conversions from lambdas to delegate types will be unaffected by params or default parameter values. Differences in those will cause a warning
later in the pipeline. Lambdas that do not have params/default parameter values will not warn when converted to delegate types with them. We will not warn for
method group conversions that differ by params or default parameter values.