A way to catch INotifyPropertyChanged from child properties automatically

[CyberBotX]

Note that I do not know how it would be done or how complex it would be to implement in this source generator.

But the general idea would be to support something like this:

partial class Parent
{
	[Notify]
	Child? _child; // Assume that the child is initially null and only set in a later method

	public bool ChildValue => this.Child?.Value ?? false;
}

partial class Child
{
	[Notify]
	bool _value;
}

So basically, right now the source generator will only make it so when the Child property on Parent changes, then there is a notification that ChildValue has changed, but if the Value property on the child gets changed, there is no notification that ChildValue has changed.

There are many ways I have seen to get around this, such as manually hooking into Child's PropertyChanged event from Parent (which could be an issue if the Child property of Parent changes as assumed above and needing to manually unhook from the PropertyChanged even later) or wrapping the Parent instance in a class that can catch child property changes (I used the classes from https://gist.github.com/thojaw/705450 and they do seem to work) or possibly using a proxy class of some sort.

PostSharp's INPC support seems to use its own INotifyChildPropertyChanged interface to facilitate this, but I'm trying to get away from PostSharp for this. I don't know exactly what their implementation does but just trying to look at it via a decompiler such as ILSpy makes it seem rather complex and possibly incurring a run-time overhead in addition to a compile-time overhead.

If this seems out of scope for this source generator, I understand. It seems like a rather complex scenario and I don't know enough about source generators to know if this sort of thing is possible with them or not.

[canton7]

Interesting. There are a couple of things that I think will make this a bit tricky:

The first is that when the source generator runs, Child doesn't actually exist yet. This means that when we inspect the body of ChildValue, we can see that it's referencing something called Child, but the compiler hasn't been able to bind that to a member, because the member doesn't exist yet. We can get away with this for simple cases: with for auto depends-on, I go searching through the type hierarchy for a property of the same name (either pre-existing, or one that I'm going to be generating). Life gets significantly harder if we're having to parse Child.Value where Child is (currently) an error, and then once we've worked out that it might end up binding to the Child property that we're about to generate, start evaluating Value: we're starting to replicate significant chunks of the compiler. Life gets completely impossible with e.g.:

public bool ChildValue
{
    get
    {
        var child = this.Child;
        // Other stuff
        return child.Value;
    }
}

Partial properties (dotnet/csharplang#3412) would make this a lot better, as the compiler would be able to bind the this.Child reference to the Child partial property before the SG runs.

IL weavers don't have this problem as bad, as they're working on IL (which is fully bound). PostSharp will still need to keep track of where intermediate variables came from as in my example above, though, which isn't simple.

Another issue is that I want PropertyChanged.SourceGenerator to be purely a code generator: I don't want the user to have to add references to DLLs. This means that I can't do something like introduce an INotifyChildPropertyChanged interface. (I could insert it into the user's assembly of course, but you hit problems if Child and Parent are defined in different assemblies.

I'm tempted to let this one stew for a while: if we ever get partial properties that will make this significantly easier.

[CyberBotX]

Fair enough on all those points. I just wanted to bring it up to see if it may or may not be possible.