Property Observers in C# like Swift

[HamedFathi]

In Swift to observe and respond to property values Property Observers are used. Each and every time when property values are set property observers are called. Except lazy stored properties we can add property observers to 'inherited' property by method 'overriding'.

Property Observers can be defined by either.

• Before Storing the value - willset.
• After Storing the new value - didset.

When a property is set in an initializer willset and didset observers cannot be called.

public class Sample {

 public int Value {
  get;
  set;
  beforeSet(value) {
   Console.WriteLine($ "Total Counter is: ${value}");
  }
  afterSet {
   if (counter > value) {
    Console.WriteLine($ "Newly Added Counter {counter - oldValue}");
   }
  }

 }
}

This can be more useful than IPropertychanged and I think can be a very very small way to gathering AOP programming based on C# syntax.

[HaloFour]

Why is this an improvement on writing that logic in the setter/getter methods? It's not like you can observe the changes of other instances, so it doesn't cover the same use cases as INotifyPropertyChanged. It seems like some weird middle ground between auto-implemented properties and normal properties but the verbosity isn't much of an improvement over normal properties.

[jnm2]

I'd much rather have the field keyword and write:

public int Value
{
    get;
    set
    {
        Console.WriteLine($"Total Counter is: {value}");

        var oldValue = field;
        field = value;

        if (counter > value)
            Console.WriteLine($"Newly Added Counter {counter - oldValue}");
    }
}

Or even in this case:

public int Value
{
    get;
    set
    {
        Console.WriteLine($"Total Counter is: {value}");
        if (counter > value)
            Console.WriteLine($"Newly Added Counter {counter - field}");
        field = value;
    }
}

[Thaina]

@jnm2 Is that #318 ?

I don't like field keyword. #318 should just be enough

[quinmars]

@jnm2

I like the idea of the of the field keyword. Implementing the INotifyPropertyChanged interface still involves some (imho too much) boiler plate code, although it already was improved in the last years.
Making a property observable needs today something like the following code:

private IEnumerable<EmployeeViewModel> _Employees;
public IEnumerable<EmployeeViewModel> Employees
{
	get => _Employees;
	set => SetField(ref _Employees, value);
}

With the field keyword this could become:

public IEnumerable<EmployeeViewModel> Employees
{
	get;
	set => SetField(ref field, value);
}

@Thaina

With proposal #318 it would look like that:

public IEnumerable<EmployeeViewModel> Employees
{
	IEnumerable<EmployeeViewModel> field;
	get => field;
	set => SetField(ref field, value);
}

You still have to repeat the type for the backing field and you have to declare the backing field. I definitely prefer @jnm2 proposal. The only problem I see, is that the field keyword can already be used as a variable name, which makes it hard to introduce it now as a contextual keyword.

[Thaina]

@quinmars

The only problem I see, is that the field keyword can already be used as a variable name, which makes it hard to introduce it now as a contextual keyword

Yes it is breaking change. That's what I said 318 is enough. Stop introducing new keyword just for lazy purpose. And also there are many possibility to work with property by more than one field. Or even using many property on one field. field keyword has just only one usage. It not worth for being keyword

[ggaabe]

I think this would be a good change. willSet and didSet are useful. There will always be a lot of people who drag their feet on language features or syntax improvements so they don't have to learn anything else their whole lives. Don't let others get you down about it.

[Bersaelor]

Now that I picked up C# after working in Swift for many years , this is the one language feature I miss most. (That and proper enum support of course)

willSet / didSet make it so much easier to reason about the flow of state. By convention, all methods that are called in response to variables changing go into the didSet. The local state of an object is in its properties and methods get called either by state changes or due to events.
When writing C# having two lines per variable defined gets tedious real fast, i.e.:

    private bool _isHidden = true;
    public bool isHidden {
        get => _isHidden;
        set {
            _isHidden = value;
            UpdateVisibility();
        }
    }

vs

    public bool isHidden {
        didSet {
            UpdateVisibility();
        }
    }

TL;DR: Please give use a willSet :)

[spydacarnage]

In the same way that INotifyPropertyChanged can use source generators and an attribute, I reckon this could, too.

[DidSet(nameof(UpdateVisibility))]

[msedi]

@spydacarnage: Do you know how far SourceGenerators can be used in productive work at the moment. According to the docs they are still under heavy development...

[spydacarnage]

They released as part of NET5 / C#9, so they're out and supported (and I'm using them).

VS2019 still needs a bit of work to improve the experience, but they are useable right now.