Open JohanLarsson opened 4 years ago
@JohanLarsson IIRC that warning is legit and it goes away if you either have code that invokes the property or you write the event so that it has no backing field.
if you either have code that invokes the property or you write the event so that it has no backing field.
Not sure how you mean
I think the warning disappears if you have PropertyChanged?.Invoke()
somewhere in the code. Or anything that reads the PropertyChanged
field. Or alternatively, if nothing ever reads the field and this is by design, the warning disappears if you declare the event as:
public event PropertyChangedEventHandler PropertyChanged { add { } remove { } }
"The event is never used" is just the event version of "the field is never read." (Assuming I'm not forgetting how it works.)
Ok, gotcha. I get why the warning makes sense.
IIRC there used to be memory leak issues when binding to properties on types that don't implement INPC and this is why I'm thinking about suppressing the warning for sealed classes.
Fo nonsealed classes we don't want to suppress as in that case we should add an invocator:
protected void OnPropertyChanged([CallerMemberName] string? propertyName = null)
{
this.PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
}
I don't think suppressing will be that bad as we have plenty of nags if forgetting to notify.
If the goal is to implement a no-op INotifyPropertyChanged, I'd personally prefer this over public member + an unused backing field + suppression pragmas:
event PropertyChangedEventHandler INotifyPropertyChanged.PropertyChanged { add { } remove { } }
event PropertyChangedEventHandler INotifyPropertyChanged.PropertyChanged { add { } remove { } }
Is problematic if we later add a mutable property. Then the fix has to rewrite the event and I would hesitate to do it.
To avoid:
There are memory leaks when binding to properties on members that do not implement
INotifyPropertyChanged
maybe it was fixed but no huge harm in implementing the interface and legacy.