Delegated properties, like in Kotlin

[AsafMah]

When using frameworks it seems that there is a lot of boilerplate surrounding Properties.
Here are some examples:

INotifyPropertyChanged

It is used in both wpf and windows universal, which make a hefty percentage of the desktop GUI apps developed today, and it makes writing binded classes very annoying, and makes them less readable.

Someone already suggested special syntax just for this interface for how annoying it is:
https://github.com/dotnet/csharplang/issues/

I don't think we need new language features just for this interface, but the problem doesn't stop here.

ReactiveUI

This framework defines two types of special properties.
Both require a backing field and boilerplate:

    string _SearchTerm;
    public string SearchTerm
    {
        get { return _SearchTerm; }
        set { this.RaiseAndSetIfChanged(ref _SearchTerm, value); }
    }

    ObservableAsPropertyHelper<Visibility> _SpinnerVisibility;
    public Visibility SpinnerVisibility => _SpinnerVisibility.Value;

The solution (In kotlin)

Kotlin has a very nice feature called "Delegated Properties".
You can read about it here: https://kotlinlang.org/docs/reference/delegated-properties.html
It looks like this:

class Example {
    var p: String by Delegate()
}

p is an auto property (all kotlin properties are), but it is delegated to the delegate class.
The delegate class looks like this:

class Delegate {
    operator fun getValue(thisRef: Any?, property: KProperty<*>): String {
        return "$thisRef, thank you for delegating '${property.name}' to me!"
    }
 
    operator fun setValue(thisRef: Any?, property: KProperty<*>, value: String) {
        println("$value has been assigned to '${property.name} in $thisRef.'")
    }
}

Basically, every time p is accessed, the corresponding method to the access type in Delegate would be called.

It lets you abstract over writing getters and setters, you only need to write the delegate class once, and now every property can use its functionality in one line.

The solution

What I propose is to add a mechanism similar to this in c#.

First, we would need to define a class.
It should have the methods GetValue and SetValue with the right signatures like this:

class NotifyHelper<T> {
    private T _val;
    public NotifyHelpe(T val) => _val = val

    T GetValue(object this, PropertyInfo property): {
                 return _val;
    }
 
    void SetValue(object this, PropertyInfo property, T value) {
             if (value == _val) {
                    return;
             }
            _val = value;
            ((INotifyPropertyChanged) this)?.PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(property.Name));
    }
}

And that's it, now you have a re-useable way to have your classes support the interface.

the syntax for using the class could look like this (it's not final at all, of course):

class Example {
String p using NotifyHelper.Create("Initial") //Create method is to avoid specifing the generic type, its definition is omitted here
int i using NotifyHelper.Create(5) 
MyCustomObject c using NotifyHelper.Create(new MyCustomObject(3)) 
}

As you can see it's pretty readable, convenient and extendable.

Other uses

The kotlin page lists other uses for this feature, notably their own version of Lazy - in kotlin, if you have a lazy property you can just define it to be your type T, instead of c#'s Lazy.
The delegated property will make sure that it is initialized late and only once, but when you use it you can treat it the same as any other string.

[iam3yal]

@AsafMah This is probably yet another use-case for #107. Check other use-cases here #341.

[aluanhaddad]

I like the idea of delegation here. It seems like some pretty powerful patterns could emerge, but I dislike the proposed syntax. I feel like it's a missed opportunity to express a relationship between a type and a property on that type by enhancing generic constraints. The example code is opaque.

[rikimaru0345]

Eyalsk: that's the first thing that came to my mind as well!

I would love to be able to do what is suggested here, but I think it could be solved in a better, more generic way.

If we get some additional syntax to delegate properties, then it won't take long for "extended" suggestions to pop up (like maybe also proxying methods).

That would bring us back to generators aka "replace original" again.

[iam3yal]

@rikimaru0345

I would love to be able to do what is suggested here, but I think it could be solved in a better, more generic way.

That generic way you speak of is source generation.

Adding a specific syntax to the language just for that means you specialize not generalize and can't see why it warrants a new syntax.

[Richiban]

Since the Source Generators feature seems to have gone nowhere I would like to resurrect this feature request...

I've been teaching myself Kotlin recently and I found this feature to be both mind-blowing in concept and insanely useful. It's general enough to solve a few of the situations that users have been asking for language features for whilst also being easy to understand (both for users and tooling) and easy to develop for.

For example, after just a few hours of learning Kotlin I was able to solve one of my pet peeves that C# has: Lazily initialised properties.

import kotlin.reflect.*

class MyLazy<T : Any>(private val initializer : () -> T) {
    var isInitialised = false
    lateinit var value : T
    
    operator fun getValue(receiver : Any?, property : KProperty<*>) : T {
        if (!isInitialised) {
            println("Initialising ${property.name}")
            value = initializer()
            isInitialised = true
        }
        
        return value
    }
}

class A {
    val someProp by MyLazy { "Hello world" }
}

fun main() {
    println("Initialising a...")
    
    var a = A()
    
    println("...done")
    
    println("a.someprop = ${a.someProp}")
    
    println("a.someprop = ${a.someProp}")
}

The code above prints:

Initialising a...
...done
Initialising someProp
a.someprop = Hello world
a.someprop = Hello world

I think this would be a fantastic feature for C# that has precedent and would allow for some controlled metaprogramming that will help users solve real-world problems.

---

PS I'm aware that the Kotlin base library has an Lazy class for just this purpose already; I wanted to implement my own without looking at that to see how easy the delegates properties feature was to use.

[asarazan]

Just to further reinforce the point: This remains the most useful feature of Kotlin, and the one I absolutely miss the most now that I work in C#. Just having a wrapper delegate over Unity's PlayerPrefs interface would make me so happy-- especially since C#'s initialization order makes Lazy nearly useless in practice.

[georgiuk]

I have proposed something similar here #1095 . I hope more people find it useful and request for it.

[orthoxerox]

dotnet/vblang#282

[HaloFour]

I'm curious how a delegated property would work around the existing limitations in the C# language or if the language would require additional changes to support them. For instance, if the delegated property initialization was lifted to a field initializer you would run into the same problem with your MyLazy implementation that the Lazy<T> class in .NET has, namely that you can't reference instance members from the delegate that you pass to the constructor.

There seems to be some interest from members of the LDG (@333fred) for a feature like this so perhaps it's worth trying to work through some implementation details to get it to a state that it can be championed and taken to LDM.

[alrz]

I would rather have an official source generator for this (partial properties being a pre requisite), rather than inventing syntax here. I think the end result will be as much clear as a direct language feature.

[alrz]

My argument being: some features are already a known scenario for a source generator. Instead of investing directly on a few popular ones, I think we should just add auxiliary features that extend the ability of generators. That way we incidentally cover way more scenarios than just a single one.

Compared to language feature, I think the biggest issue is actually writing the generator which is not everyone's piece of cake. And that will be resolved once this is available as a nuget package, either official or third party.

[333fred]

I am indeed interested in the idea of delegated properties, but I haven't yet come up with a proposal that I like. I'll post some of my notes and ruminations on the topic for general viewing though:

Exploration: Delegated Properties

There are several proposals on dotnet/csharplang for enhancing the expressiveness of properties without falling back to a fully manual property syntax. @jnm2 has helpfully put together a gist tracking these (thanks @jnm2!), which can be found here. There are still other proposals for a more powerful enhancement: delegated properties.
Miguel created one, #2657, called property wrappers. While I'm using the name delegated properties in this exploration, they are basically the same base concept. Another existing proposal is #1096.

Motivation: What is a delegated property and why do I want one?

At its core, a delegated property is a way of taking a common pattern used in propety implementation and abstracting it out, allowing it to be reused in multiple places. There are two signature examples that I used to inform this exploration, which are also some of the most common examples brought up when we look at proposals for the field modifier or the other simpler proposals tracked in the gist above:

• Creating properties on an type that implements INotifyPropertyChanged. This is an incredibly common pattern used all over UI programming; so common, in fact, that most UI libraries ship with a helper for this. ReactiveUI, for example, has RaiseIfChanged. Fody has a plugin that will implement this for you, as does PostSharp. Googling INotifyPropertyChanged (just that!) leads to multiple StackOverflow examples of creating similar helper methods, before any StackOverflow posts on actually understanding the interface or what it's used for. The core pattern here is also very simple: in the setter, if the property value has changed, raise an event.

• Initializing properties lazily. There are actually two main sub-elements in this one:

  • Using something like InterlockedInitialize, where the computation can run multiple times or is only requested from a single thread, or;
  • Using a full Lazy<T> instance.

  In either case, the pattern is very similar: in the getter, if the property has not yet been initialized, initialize it, then return the result.

• Property validation. While we have an outstanding proposal and interest in compile-time validation of property values, we could provide runtime enforcement via a delegation method that either keeps a value within range or throws on invalid input.

There are, of course, many other types of patterns that you might want to abstract out for convenience. Miguel's wrapper proposal has a few examples, like logging or atomic implementation. This removes a bunch of boilerplate and allows the intent of the code to be more obvious to the reader.

Types of delegated properties

Before we consider an explicit design for delegated properties, I think it's important that we try and categorize different types of delegated properties by what they need to work:

Storage

Some delegated properties require storage for an entirely new type, like Lazy<T>. Lazy<T> requires additional space to store the current state of the Lazy, including whether computation has started. On the other hand, a hypothetical InterlockedLazy<T> would not require any more storage than the T used. Similarly, an INotifyPropertyChanged helper wouldn't need any extra storage, provided the helper that can raise an event on the containing type is passed as a parameter to the set helper. Both of these last two examples would need access to the location where the value is stored, but they wouldn't necessarily need to store the value themselves.

Parameterization

Almost every realistic delegated property example that I've been able to come up with needs some form of parameterization beyond just the value being set. The one example that I've seen that could be generally applicable is something like the Atomic wrapper proposed in Miguel's example, but that is a narrow enough example that I'm not convinced we need to design explicitly for it. Rather, I think the interesting distinction is between delegated properties that need a callback of some kind, and those that do not. All forms of Lazy and Interlocked need a callback to create the initial value when required, and an INotifyPropertyChanged implementation will also need some form of callback to raise the event in the class. However, things like logger or validation wrappers might not need these callbacks. They'll still need parameters (what log channel/message to use, min/max value, etc.), but these parameters are not arbitrary code.

A possible design for delegated properties in C#

What follows in this section is a possible solution to introducing delegated properties in C#. My main concerns in this exploration were in allowing the expression of both storage-requiring and storage-non-requiring properties. I also mostly focused on helpers that require arbitrary-code callbacks, but I don't believe that there is a significant blocker in creating delegated properties that are simple wrappers. I did not, however, focus on one aspect from Miguel's proposal, namely composition over multiple of these wrappers. I believe that you could use the pieces in this exploration to create such a system without having to build in explicit support for it, and that it would fit better into C# as a whole.

Definition

I always like having an example of code to start with, and then dig into that example with explanations of how it works, so that's what I'm going to do here. Using the motivating examples from above, here's how you would implement INotfiyPropertyChanged, InterlockedLazy<T>, Lazy<T>, and Clamp. I'm going to use == for simplicity of writing examples here, but a real implementation would need to replace with EqualityComparer<T>.Default.Equals, as appropriate (and might even parameterize that comparer).

public static class InterlockedLazy
{
    public static TValue Get<TValue, TCallback>(ref TValue field, TCallback callback) where TCallback : ref struct, IInvocable<TValue>
    {
        if (field == default(TValue))
        {
            Interlocked.CompareExchange(ref field, callback(), default(TValue));
        }

        return field;
    }
}

public struct Lazy<TValue>
{
    private object _lock;
    private TValue _value;

    public void Get<TCallback>(TCallback callback) where TCallback : ref struct, IInvocable<TValue>
    {
        if (_value == default(TValue))
        {
            return _value;
        }

        lock (_lock)
        {
            if (_value == default(TValue))
            {
                return _value;
            }

            _value = callback();
            _isInitialized = true;

            return _value;
        }
    }
}

public static class NotifyPropertyChangedHelper
{
    public void Set<TValue, TCallback>(ref TValue field, TValue newValue, TCallback callback, [CallerMemberName] string caller = "") where TCallback : ref struct, IInvocable<string>
    {
        if (field != newValue)
        {
            field = newValue;
            callback(caller);
        }
    }
}

public static class Clamp
{
    public void Set(ref int field, int newValue, int maxValue, int minValue, [CallerMemberName] string propertyName = "")
    {
        if (newValue > maxValue || newValue < minValue)
        {
            throw new InvalidArgumentException(propertyName);
        }

        field = newValue;
    }
}

The general pattern is, on any type T, we recognize methods that have the signature Get or Set. These methods can be used to delegate the property P on class C'. If the T containing the Get or Set is a static class, then the first parameter must be a ref of the type of P, and no storage is allocated for this helper. If the T containing the Get or Set is a class or struct, it must provide the storage for the property, and the backing field in C' for P is of type C. Set methods must take an additional parameter by value of the type of P in the second parameter. The next parameter is a callback, if necessary. This can be a standard delegate type that we have today, or a potentially new callback type that I'll briefly outline in the next section. Finally, other parameters to the delegated property, as necessary.

Value delegates

In exploring this space, several LDM members brought up a concern that they would like to see delegated properties give as little of a perf hit as possible. Part of this is expressed in this exploration by letting property wrappers be both static classes and structs, , ensuring that we use as little extra space as possible. However, as I covered in the Parameterization section, many examples of property wrappers need to able to parameterize code from the class using the delegated property. INotifyPropertyChanged needs to provide a method that can invoke the changed method, the Lazy variants need to provide a method to create the value, etc. So, as part of this exploration, I wanted to look at a possible way to achieve this. This needs a more comprehensive solution that I hope we address as part of type classes in C# 10, but I think that we can base the solution off ref structs. Here, by allowing the TCallback to be a ref struct that implements some interface that can be invoked, we create what I'm calling a value delegate. Note that this is not a replacement for static delegates; we're doing function pointers in C# 9 and I don't think we'll be doing anything with the static delegates proposal. Rather, this is an approach to allocationless delegates that can still capture local state, but are guaranteed to be stack-only and thus we don't need to create anything on the heap, lift things to display classes, or any of the other traditional heavy lifting we have to do for delegates. This is not a full proposal for this feature, as I think that needs significantly more time to come up with a coherent set of rules, so for this exploration just treat it as a handwave. In particular, the constraint needed here is ugly, and it would be painful for it to have to bleed everywhere. A better solution might be ref interfaces, but in order to get this exploration out the door I'm going to stick with the examples I already have typed up :).

Usage

Now that we've seen how to define delegated property helpers, let's look at how to use them. Again, I'll start with examples of usage, and then explain how it works:

public class C
{
    private string MyExpensiveStringCreatingOp() { ... } // Omitted

    public string LazyProp1 as InterlockedLazy<string>
    {
        get(MyExpensiveStringCreatingOp);
    }

    public string LazyProp2 as Lazy<string>
    {
        get(() => { ... /* Other expensive string operation, omitted */ });
    }

    public int ClampedProp as Clamp
    {
        get; set(-1, 1);
    }
}

public record MyViewModel(int Prop1, int Prop2) : NotifyPropertyChangedBase /* Defines the event, and a helper to raise the event RaiseIfChanged */
{
    int Prop1 as NotifyPropertyChangedHelper
    {
        get; set(RaiseIfChanged);
    }

    int Prop2 as NotifyPropertyChangedHelper
    {
        get; set(RaiseIfChanged);
    }
}

Here, we define a new part of a property declaration: the as Type section. The Type specified must fit the delegated property pattern specified above. We perform overload resolution to find the best fit, using whether the Type specified is a static class or struct/class to determine whether the first parameter should be a ref of the property type. If the accessor is a set, the parameter after the ref field (if present) is the newly set value. The rest of the parameters are resolved using the explicit parameter list, if provided. If Type is a struct or class, then the only legal accessors are the ones provided by Type. If Type is a static class, then it is legal to have a bare get or set. If an as Type clause is present and no helper from Type is invoked, then an error is produced.

Thoughts on this approach

Throughout this exploration, I've been careful to avoid calling it a proposal. It has the start of a proposal, but in the course of putting this together I've come to believe that full delegated properties, as seen here, are far too complicated and specific a topic to make it to 100 points for me. Rather, I think that we can achieve 90% of what this proposal offers by enabling a combination the the field identifier and having field-scoped properties. For example, 3 of my 4 motivating examples are trivially solved with the field keyword (InterlockedLazy, INotifyPropertyChanged, and Clamp), and the other one is mostly solved by property-scoped fields (Lazy). And then we can get to that final 99% by enabling a general concept of value delegates that are nearly as cheap as a regular function call.

That's not to say there's nothing good about this exploration, and that we should throw out all of it. We've had some internal discussions around allowing the backing field of a property to be different from the type of the property (the catalyst for publishing this exploration, in fact). The current internal strawman is something like like:

public string? P { get => field.Value; } = new Lazy<string?>(Compute);

I've internally voiced disagreement with this approach, because using the assignment as a method of determining what the backing field type should be is brittle and lacks intent. However, we can take the as Type syntax from this proposal and apply it there, thus ensuring that the intent of the programmer is clearly conveyed in a way that isn't brittle to the addition of new conversions.

Additionally, I think the concept of value delegates via ref interfaces is an interesting one that we should explore in detail.
It would be an important stepping stone in a hypothetical allocation-free LINQ and other performance optimizations that must currently hand-write code or fall to unsafe (or il-generation!) in order to get the perf characteristics that they require.

[jnm2]

Are instance methods going to be able to be referenced in property initializers and property-scoped field initializers? That's necessary for the Lazy<T> examples.

[333fred]

@svick @alrz I totally agree with your thoughts on clarity, which is why I haven't found a delegated properties proposal I like yet. @jnm2 yes, they'd have to be able to see this or they're basically useless.

[Joe4evr]

@333fred So I believe the reason accessing this in an initializer isn't legal today should be sound, but I wonder if the following relaxations are good enough to make it work without compromising the safety too much:

• Given this sample use-case:

  public string? Computed
  {
      Lazy<string?> l = /* this is where we want to access 'ComputeValue()' */;
      get => l.Value;
  }
  private string? ComputeValue() { /*......*/ }

  • An instance member (method?) can be accessed if it is directly converted to a delegate via method group conversion (eg. Lazy<string?> l = new(ComputeValue))
  • An instance member can be accessed if it is accessed inside of a delegate expression (eg. Lazy<string?> l = new(() => ComputeValue()))

[alrz]

@Joe4evr Is there any point to restrict what is accessible? I think if it's done it should be just spec'd as an accessible this. (VB already support that).

[HaloFour]

I agree, additional restrictions aren't really helpful here. There's nothing about converting the instance members to a delegate and passing it to some type that is any safer than invoking the instance members directly. Whatever you pass that delegate to can invoke it immediately.

Either way, the only way to support accessing instance members from the property-scoped field initializers is for those initializers to run sometime after the base constructor call, whether that would be immediately after the base constructor call or at the end of the constructor. At that point the can of worms is open and you might as well lift the restrictions in general.

The fact that you can't reference instance members from field initializers is a relic of the decision to run those initializers before calling the base constructor. The reason for doing so is sound, but as @alrz already mentioned VB.NET chose differently from the outset and it has not been a source of confusion or bugs.

[msedi]

I just want to give a few thoughts of mine here. I had this problem several times, but some problems that are discussed here only mostly deal with INotifyPropertyChanged which is (at least in my opinion only made for the connection to WPF property bindings).

We are currently strictly following the MVVM pattern where we really always have a model and a viewmodel and a view. But our applications are also made such that I don't need a viewmodel and view at all, since most of our applications also need to run in command line mode. So we not only have MVVM but we also have some sort of an interprocess barrier between model and viewmodel.

I my early days both, the model and the viewmodel implemented INotifyPropertyChanged where the viewmodel listened to the model. The problem was that INotifyPropertyChanged has only the property name in it which was in most cases insufficient for us. So we decided to use observables for our models (but it would of course also work with events). We chose observables because we also need to transfer other data to the viewmodel than only INotifyPropertyChanged.

In the following example I will use the name DependencyObject (DO) which you already know from WPF (this is for a reason, I will explain later).

So here are a few points what was our requirements:

1. Prevent repetitive code
We introduced

SetProperty<T>(T value, [CallerMemberName]string propertyName = null);

and

T GetProperty<T>([CallerMemberName]string propertyName = null);`

which does the internal mechanics to store the properties and also check against already set values, because also here for performance reasons we didn't want to invoke unnecessary events if the value is already set. Inside there is a ConcurrentDictionary<string, object> that stores the values for each property, of course here the property is that I need to do an additional lookup and have boxing problems, but this is what I currently cannot get around with C# but we accepted this. SetProperty also invokes the INotifyPropertyChanged handler if the value has changed or in our case, since the model is an Observable<> we post a more complex PropertyChangedEventArgs to the Observer<>.

For a new class you then simply have to write

public class NewObject : DependencyObject
{
  public int Value1
  {
    get=> GetProperty<int>(10);
    set=> SetProperty<int>(value);
  }  

  public int Value2
  {
    get=> GetProperty<int>(10);
    set=> SetProperty<int>(value);
  }  
}

2. Block the immediate transport of changed properties
One reason was for example that we wanted to block the immediate transport of the changed property to the viewmodel (or the view), because so many properties where changed that we need severe performance drops.

This was solved by putting a BeginUpdate/EndUpdate around property changed to lock the updates and could be done like this:

NewObject DO = new();
DO.BeginUpdate();
DO.Value1 = value1;
DO.Value2 = value2;
DO.EndUpdate();

or by

NewObject DO = new();
using DO.BeginUpdate();
DO.Value1 = value1;
DO.Value2 = value2;

Of course you could also use SetProperty and GetProperty, but then you need to take care about the types yourself.

NewObject DO = new();
using DO.BeginUpdate();
DO.SetProperty(value1, "Value1")
DO.SetProperty(value2, "Value2")

One advantage of this was/is that you can also call CancelUpdate() to undo all changes, since it also has some mechanisms to store the current state if requested.

And here is the point why INotifyPropertyChanged was mostly useless, because it only sent one property name or [Null] for a dramatic change, but it wasn't granular enough for our needs. We can also send the old value and the new value for each property so that we can react more on the changes.

3. Default values
Each property should have a default value which can either implicitly done by using GetProperty with a default value or by registering a default value via RegisterProperty.
Internally a dictionary is used to store default values and other data for the property.

There's also a ResetProperty to remove the current value and take the original default value.

4. Value coercion
Often it is necessary to force a property value into a given range. This is normally done in the viewmodel (sometimes also in the view) but since we have also commandline only tools, we needed this in the model also. So as said above there is an internal list that stores meta information about the property in a dictionary, where we can also store a CoerceValue handler to force the value to a certain range given by the handler (if a handler is given).

5. Value binding
We also have the problem that some objects are dependent on properties of other objects (BindProperty).
For that reason you can also bind to other properties and react on their changes and values.

6. Value inheritance
Sometimes we have some sort of child objects that mostly hold the values from their parent objects (like in a tree). Accessing a values follows up the dependency tree up to the root until it hits a value. You can override their values so that they deliver immediately their own values.

7. Value generation
We have a very complex state machine with hundreds of nodes, where it doesn't make sense to compute the node if no one uses the value. Only if the property is accessed the value is computed, so also have some sort of lazyness in the object which is also done to not have repetitive and especially here error prone code.

All in all I don't want to tell what things we made but what things were necessary for us and while we were improving our own structures we found that this is WPF DependencyProperty which does all the work but unfortunately it's WPF only and uses the dispatcher internally which we cannot use in command line. So maybe having something like a DependencyObject (without WPF) would be cool.

I don't think it's worth a language change but some more assistance to get around boxing problems might help. Especially where I need to store an in a object because I can currently do not better. Source Generators could also help in general to prevent repetitive code.

Just some thoughts...

[gulshan]

As the field keyword is being included in the language, I think I would make a bump here. And here are some of my thoughts regarding the issue:

I have found that, the delegated properties are useful mainly in the cases when the backing field is of a different type from the property it is backing. In .net, usually we see the properties and the backing fields are of the same type. But sometimes it can be very useful to have a backing field of a different/complex generic wrapper type and then expose the property with getters and setters with a simple type. The first example of a wrapper type for the backing field would obviously be the Lazy<T> type. The second one I have encountered was an INPC implementation in the library Assisticant. It also uses a wrapper type Observable<T> for in-program notification management. And it was the most elegant INPC implementation I have seen in C#.,

So, I think, the delegated properties should be built upon this concept of generic wrapper types for properties, which implements some interfaces with getter/setter providers. If I borrow from Kotlin, the interfaces will be something like-

public interface IReadOnlyProperty<T, V>
{
    V GetValue(T thisRef, string propertyName);
}

public interface IReadWriteProperty<T, V> : IReadOnlyProperty<T, V>
{
    new V GetValue(T thisRef, string propertyName);
    void SetValue(T thisRef, string propertyName, V value);
}

And any wrapper type implementing any of these two interfaces will be able to act as a "delegated property provider".
As C# already has the by contextual keyword, it can just follow Kotlin in the delegated property syntax like this-

class Person {
    string Id by new Lazy<string>(/*init*/);
    string Name by new Observable<string>(/*init*/);
}

Was trying to put some high-level ideas about the proposal. Really want to see this proposal going forward in C#.

[Matt-17]

I really like this idea as I have seen this only today. But I dislike the syntax of the proposal. So I'd like to introduce my idea for a syntax for Delegated Properties. Basically the usage should be as simple as possible and also familiar. That's why I suggest following idea.

ObservableProperty should be a user-defined class with the following methods:

public class ObservableProperty<T> : System.Property 
{
    public T Get(object owner, ref T field, [CallerMemberName] string propertyName = "") { ... }
    public void Set(object owner, ref T field, T value, [CallerMemberName] string propertyName = "") { ... }
}

public string MyObservableProperty : ObservableProperty { get; set; } 
public string MyLazyProperty : LazyProperty { get; set; } 

In general I would ignore the Property string of this. This is similar to Attributes and would look like this:

public string MyObservableProperty : Observable { get; set; } 
public string MyLazyProperty : Lazy { get; set; } 

The compiler could transform this into something like this pseudo code:

private string <MyProperty>_field;
private ObservableProperty<string> <MyProperty>_delegate = new ObservableProperty<string>;

public string MyProperty
{
    get 
    {
        <MyProperty>_delegate.Get(this, ref <MyProperty>_field);
    }
    set 
    {
        <MyProperty>_delegate.Set(this, ref <MyProperty>_field, value);
    }
}

This approach allows custom usage of the delegate as well to implement further stuff if really needed.

public string MyProperty : Observable 
{
    get 
    {
        Get(this, ref field, "MyProperty");
        Console.WriteLine("MyProperty was read");
    }
    set 
    {
        Set(this, ref field, value, "MyProperty");
        Console.WriteLine("MyProperty was changed.");
    }
}

this would define Get(..) as a keyword method. Of course it could be set(), delegate.Get() or something similar.

In my opinion, this would not require changing the CLR. If need, there could be a default property, which would be implemented like this:

public class DefaultProperty<T> : System.Property 
{
    public T Get(object owner, ref T field, [CallerMemberName] string propertyName = "") => field; 
    public void Set(object owner, ref T field, T value, [CallerMemberName] string propertyName = "") => field = value; 
}

full example

As example, I would give this, what would be already possible.

public partial class MainWindow : Window
{
    public MainWindow()
    {
        InitializeComponent();
        DataContext = new MainViewModel();
    }
}

public class MainViewModel : INotifyPropertyChanged
{
    private string _myString = "Hello, World!";

    private readonly ObservableProperty<string> _myStringDelegate = new();

    public string MyString
    {
        get => _myStringDelegate.Get(this, ref _myString);
        set => _myStringDelegate.Set(this, ref _myString, value);
    }

    public event PropertyChangedEventHandler? PropertyChanged;

    public virtual void OnPropertyChanged([CallerMemberName] string? propertyName = null)
    {
        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
    }
}

public class ObservableProperty<T>
{
    public T Get(object owner, ref T field, [CallerMemberName] string propertyName = "")
    {
        Debug.WriteLine($"We really like logging Get for {propertyName}.");
        return field;
    }
    public void Set(object owner, ref T field, T value, [CallerMemberName] string propertyName = "")
    {
        if (EqualityComparer<T>.Default.Equals(field, value)) return;
        field = value;
        if (owner is MainViewModel b) // Used MainViewModel for simplicity. 
            b.OnPropertyChanged(propertyName);
    }
}

This would change to the following making it much easier to write and also to read.

public partial class MainWindow : Window
{
    // Same as above
}

public class MainViewModel : INotifyPropertyChanged
{
    public string MyString : Observable { get; set; } = "Hello, World!";

    public event PropertyChangedEventHandler? PropertyChanged;

    public virtual void OnPropertyChanged([CallerMemberName] string? propertyName = null)
    {
        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
    }
}

public class ObservableProperty<T> 
{ 
    // Same as above
}

I would like some comments, if I missed something.