There should be an easy clean way to implement INotifyPropertyChanged on auto properties

[AdamEctobox]

I tried to submit this from the dev community site but it got pushed to the rosyln project for reasons.

This issue has been moved from a ticket on Developer Community.

Auto Properties are wonderful compared to how verbose they were before

public string Title { get; set; }

Is much better than:

public string Title
{
    get
    {
        return title;
    }
    set
    {
        if (title == value)
        {
            return;
        }
        title = value;
    }
}

But if we need to use INotifyPropertyChanged to support an MVVM pattern we are forced back into the bad old days. This is a frequent problem that leads to hundreds of extra lines of ugly code and time lost.

This:

public class DeployProfile : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler? PropertyChanged;
    private void NotifyPropertyChanged([CallerMemberName] String propertyName = "")
    {
        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
    }
    string title;
    public string Title
    {
        get
        {
            return title;
        }
        set
        {
            if (title == value)
            {
                return;
            }
            title = value;
            NotifyPropertyChanged();
        }
    }
}

Should be able to be written as:

public class DeployProfile : INotifyPropertyChanged
{
    public string Title { get; set; notify; }
}

or even

public class DeployProfile
{
    public string notify Title { get; set; }
}

I do not believe hacky 3rd party code generators are a good solution here. They have been around for over a decade and only serve as a grubby band-aid rather than a clean, elegant solution in the language itself.

[CyrusNajmabadi]

Hi Adam. Could you use markdown blocks to clean up the code samples? Thanks! :-)

[AdamEctobox]

Done

[iam3yal]

This can easily be solved by SC.

You can easily make a SC and annotate your field/property with some attribute say GeneratedIPC.

Maybe something like this should be included in the framework.

[Richiban]

The language isn't going to tell you to "biff off" (I'm stealing this phrase) but your use case is exactly why the language team invented source generators; to give you the ability to automate this kind of boiler plate without them having to make changes to the language itself.

I'm still not really grokking your objection to source generators. This particular source generator has already been written as is out there in the wild, just waiting for you to use it. I'm not sure how adding a NuGet package "bloats" your code.

[AdamEctobox]

I'm not saying they don't work, I'm saying that adding it to the language would be nicer. If it isn't worth the effort that is ok.
Can you truly see no downside to adding a 3rd party nuget package to a project?

[HaloFour]

Can you truly see no downside to adding a 3rd party nuget package to a project?

Out of curiosity, is the problem that it's a NuGet package, or that it might be 3rd party?

The vast majority of what I work on does require external dependencies, the concept that it's unpalatable to take dependencies on third party components is foreign to me.

[CyrusNajmabadi]

Can you truly see no downside to adding a 3rd party nuget package to a project?

Given that Roslyn itself is built off of 3rd party nuget's, not in general no. There is of course always some potential problem. But this isn't about adding random packages. This is about adding well-known, well-maintained, high quality packages. In that case, i don't see any problem at all :)

[Richiban]

Not to mention the fact that source generators are almost universally build-time-only dependencies, meaning that they don't add anything at all to your compiled app.

[franchyd]

I do not believe hacky 3rd party code generators are a good solution here. They have been around for over a decade and only serve as a grubby band-aid rather than a clean, elegant solution in the language itself.

https://learn.microsoft.com/en-us/dotnet/communitytoolkit/mvvm/generators/observableproperty seems pretty clean/elegant and thats just one example. Prior to Source Generators becoming first class citizens yeah they might have been hacky, but not anymore.

[CyrusNajmabadi]

Years?! Explain to me how this small QOL feature that I suggested in good nature could take years.

First, we'll have to design it. That will likely take a long time as people will have strong opinions on how it should work. Heck, I'm sure there will be huge discussions on things like thread safety. And we likely won't get to the design for a long
given how many large and complex things we're working on

Then we have to actually fit it into a release. Right now we're entirely full for at least a couple of releases.

So there is no realistic way of this happening for at least 2 years. And then it will have to go through a full product cycle before being released.

This is a prime reason why we created generators. It allows solving these problems in a parallel fashion with extremely low costs. The ecosystem and community have embraced them heavily as well. Cheers :-)

[CyrusNajmabadi]

I mean, there are lots of possibilities but if you're doing anything with a UI you pretty much have to implement INotify.

Sure. But our point is simply that that use case has a good solution today. You've decided to reject it, but that's not a good enough reason for us to take on this work without a very solid case behind it.

I know you guys kinda turned your backs on native windows apps but some of us still use them at want them to be easier to work with. That's all I want out of this.

Sure. Imo the generator is a great way to make this raise easier for you :-)

I'm not asking for your first born or to eat your lunch.

@AdamEctobox this is needlessly antagonistic. People are bringing up good points and your acting as if they're not and that the objections aren't warranted and are instead due to people overreacting to you. I suggest you please consider that people here are acting in good faith and are sharing their true views on how they see the situation. Thanks! :-)

[iam3yal]

@AdamEctobox Feedback, Resources, Prioritization, Design, Implementation, Testing... and whatnot or you think the process of language design especially a mature and widely used language is a hasty process?

[AdamEctobox]

We are going to have to agree to disagree here. I think you are reading hostility where none was intended and I'm sorry for that.

If you guys can't see any way that adding a 3rd party lib to a project could have a negative impact on it then we're just to far away to see eye to eye. I also am not disputing that the generator works, I'm saying adding it to the language would be a nicer solution. If you say it isn't worth the effort, that is fine. Let's leave it at that.

[CyrusNajmabadi]

I think you are reading hostility where none was intended

I think the issue was primarily with mischaracterization. You were acting as if the reaction to you was because people were viewing this as if you were doing something awful or innapropriate (the "asking for your first born or to eat your lunch" analogy). That's not what is happening. Your ask is reasonable. But so are the responses giving other opinions, esp. to why this seems unnecessary given existing solutions :)

[CyrusNajmabadi]

then we're just to far away to see eye to eye.

Well, you haven't given any reasons. So it's hard to come to a common understanding on why you feel this way. As both Halo and I have mentioned, using 3rd party packages is completely the norm. Even our own 1st-party MS packages are built on numerous first, second, and third party packages. To us, it's normal. So you having a blanket ban on them puts you squarely in a different category. And that category is one we realized a long time ago we could never keep up with. Just as you would like this one-off lang feature, so do many other millions of devs. SGs serve to bridge that gap, allowing the community, in parallel, to fill the places we don't view as being worthwhile enough for direct lang support.

Given that we designed and built SGs directly for this purpose, and the vast majority of the ecosystem has no problem using them, can you blame us for not jumping at the idea of then codifying this into the language?

I'm saying adding it to the language would be a nicer solution

I just wanted to address this (as one of the language designers). I actually disagree with this assessment. INPC is niche enough, and focused on just one area, that i don't think it should get direct language support. Furthermore, there are non-trivial questions the language would have to decide on and then stick with that decision forever on. Such domain problems are better served with domain solution IMO. Cheers :)

[iam3yal]

@AdamEctobox The issue is some of us here been here for too long and I can tell you that we have seen it all and many times people think that for some reason their problems is unique even though there is a common way to solve it within the .NET ecosystem and when you're not accepting it then there's nothing really we can do about it, I can tell you that we care dearly about this community, I do.

We do understand the impact and the issue of adding 3rd-party components, there are many kinds of developers here and we use them too! now, depending on the project, imagine that adding a library shouldn't be taken lightly! and many times so when it's about adding a feature to a language that will forever be there.

[AdamEctobox]

Extremely easy and extremely clean. there you go.

This is the reason I said maybe they should include it in the framework... I doubt the LDT would consider adding anything specifically to IPC.

It's seems to be a common theme for some people where they think the usage of NuGet packages, SC or alternatives are workarounds simply because they aren't baked in to language or the framework, It's absurd.

There is a pretty big difference between this and adding 5 letters to an auto property declaration.

I'm not really seeing the big difference. This is simple and clear:

[ObservableProperty]
private string? name;

And, as mentioned before, language changes are extremely costly. This would certainly take years to develop, would only solve this narrow case, and would only be available in a far future lang version. As opposed to generators, which solve many cases, can be used in any compiler that supports them. :-)

That answer is kinda disingenuous, you're showing a PRIVATE property and not the rest of the code that I have to add.

[CyrusNajmabadi]

That answer is kinda disingenuous, you're showing a PRIVATE property and not the rest of the code that I have to add.

Not sure what you mean. That's the only code you have to add.

[Richiban]

@AdamEctobox I suggest you install the Source Generator mentioned and give it a go. You'll quickly see that it basically is the feature that you've asked for.

[HaloFour]

I do believe that the lack of AOP or partial properties is reasonable to call out as a friction here, in that to use the source generators you have to declare the implementation details and the generator will emit the contract, and I feel that this is backwards.

[CyrusNajmabadi]

Partial properties is something we're working on.

[franchyd]

To be clear this is what you would have to write to achieve the exact thing you want:

[INotifyPropertyChanged]
public partial class DeployProfile
{
    [ObservableProperty]
    private string title;
}

This will automatically create a "Title" property that implements INotifyPropertyChanged with no additional code from you. Its just about the same thing as your desired language change but it exists today and now.

[sab39]

Isn't this one of the main use cases for semi-auto properties (which are - hopefully! - coming in the next language version)?

public string Title { get; set => SetProperty(ref field, value); }

where SetProperty is a very simple helper method using [CallerMemberName]. Barely more verbose than putting an attribute on it and no source generators involved.

[BreyerW]

Im not 100% sure but i think if one of accessors isnt autoprop then the other also cannot be autoprop. In other words get; will actually end up being get => field;

[333fred]

No, @sab39 is correct.

[TonyValenti]

I used post sharp and it solves this problem for me.