-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support initializers in semi auto property #58512
Support initializers in semi auto property #58512
Conversation
/// </remarks> | ||
internal void MarkBackingFieldAsCalculated() | ||
{ | ||
Interlocked.CompareExchange(ref _lazyBackingFieldSymbol, null, _lazyBackingFieldSymbolSentinel); | ||
((SynthesizedBackingFieldSymbol)_lazyBackingFieldSymbol)?.MarkIsBoundToFieldKeywordAsCalculated(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No tests currently cover this. I'll either remove it if it's redundant or add a test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No tests currently cover this. I'll either remove it if it's redundant or add a test.
Let's try getting into a working mode when a change without a proper testing is not presented for a review. If you'd like to make a change that changes a behavior, try starting with a test first.
Here my initial thoughts. I haven't looked at any of the changes in this PR, so it is quite possible that my opinion will change after looking at the changes in more details.
It is my understanding that we haven't figured out the design for the initializers. I.e. we are not sure when they should be allowed and what they are supposed to do. Therefore, doing any work to enable them is premature, in my opinion.
That wasn't involving changing any behavior or enabling any new scenarios. A pure refactoring, that is meant to clean up some usages like the
Does it also focus on usages
I already commented on the desire to enable initializers. I would prefer putting this on hold for now. BTW, supporting initializer was way down in our initial plan at #57076 (comment). Other things that I think we should figure out is whether we like |
@AlekseyTs Most usages of
|
I recommend putting this PR on hold for now and start working on pure refactoring PR that has nothing to do with semi-auto properties as the plan suggested. It would be fine to identify places that might need future adjustments and mark them with PROTOTYPE comments. If you are not sure what to start with, start with clean up of the |
@AlekseyTs I interpreted #57076 (comment) as "let's start reviewing API usages"
This PR is currently focused on usages of
IsAutoProperty
, specifically adjusting theCheckInitializer
call.This caused the number of accessor binding to change in some cases. I can't think of a way that we can reduce the number back.
I didn't continue reviewing other API usages to keep the PR more focused and minimal as possible.
Test plan: #57012
Proposal: dotnet/csharplang#140