[Proposal]: Auto-generated fields in expression-bodied members

[mstaros]

Auto-generated fields in expression-bodied members

• Proposed
• Prototype: Not Started
• Implementation: Not Started
• Specification: Not Started

Summary

New syntax is suggested for expression-bodied members where expression contains a method call. If this method has
ref parameter and argument contains keyword slot - it means that for this parameter compiler will generate
anonymous field of the same type.
For static member it is a static field, for instance member- an instance field.
The identity of the field = memberContainingTypeName + memberName +methodContaingTypeName+ methodName+ parameterName ;
Names of parameter that generate fields are used as field aliases. The same aliases inside the same member refer to the same field.
Absent alias is denoted as _ because the field is completely unobservable inside the member definition.
Only limitation -usage of two overloaded ref-methods with the same name for the same member should be forbidden.

Motivation

To avoid tedious code repetition with manually created fields.

Example

 public class A
{
    //generates fields  for parameters target, initialized, synclock
    int X => LazyInitializer.EnsureInitialized<int>(ref slot _, ref slot _, ref slot _, () => 1);

    int GetNewId() => Interlocked.Increment(ref slot _);

    static T Z<T>(int a) => B.Cache(a, ref slot _, ref slot _);  //generates static fields for parameters: cache, lck


    string Y
    {
        get => B.Getter(ref slot x);  // generate backing field  with internal (to member scope)   alias x
        set => B.Setter(value, ref slot x);  // generate backing field with internal   alias x
    }
}

class B
{
    public static T Cache<T>(int x, ref Dictionary<int, T> cache, ref object lck)
    {
        T calculate(int z) { ...}
        lock (lck)
        {
            if (cache.TryGetValue(x, out var v))
            {
                return v;
            }
            else
            {

                var retval = calculate(x);
                cache.Add(x, retval);
                return retval;
            }
        }

    }
    public static void Setter(string value, ref string backing)
    {
        static void OnPropertyChanged(string v)
        {
            ...
            }

            if (value != backing)
            {
                backing = value;
                OnPropertyChanged(value);
            }
        
     
    }

    public static string Getter(ref string backing)
    {
           
        return backing;
    }
}

Drawbacks

Alternatives

Comparision with delegated properties #4005 (reply in thread)

Unresolved questions

Design meetings

[HaloFour]

This is more or less a dupe of #140, which is championed. The difference is that proposal looks to repurpose the contextual field keyword to refer to this automatic backing field if no other identifier by that name is in scope.

[YairHalberstadt]

Hi

Just a suggestion for the future

If you write csharp after the backticks like so:

```csharp
code goes here
```

It syntax highlights your code:

 public class A
    {
       //generates fields  for parameters target, initialized, synclock
        int X => LazyInitializer.EnsureInitialized<int>(ref _, ref _, ref _, () => 1);

    
        static T Z<T>(int a) => B.Cache(a, ref _, ref _);  //generates static fields for parameters: cache, lck


        string Y
        {
            get => B.GetterSetter(default, ref _,  true);  // generate backing field  
            set => B.GetterSetter(value, ref _ ,  false);  // generate backing field  
        }
    }

    class B
    {
        public static T Cache<T>(int x, ref Dictionary<int, T> cache, ref object lck)
        {
            T calculate(int z) { ...}
            lock (lck)
            {
                if (cache.TryGetValue(x, out var v))
                {
                    return v;
                }
                else
                {

                    var retval = calculate(x);
                    cache.Add(x, retval);
                    return retval;
                }
            }

        }
        public static string GetterSetter(string value, ref string backing,  bool isGetter)
        {
            static void OnPropertyChanged(string v)
            {
                    ...
            }


            if (!isGetter)
            {
                if (value != backing)
                {
                    backing = value;
                    OnPropertyChanged(value);
                }
            }
            return backing;
        }
    }

I find it much easier to read like that!

Thanks

[mstaros]

Hi

Just a suggestion for the future

If you write csharp after the backticks like so:

code goes here

It syntax highlights your code:

 public class A
    {
       //generates fields  for parameters target, initialized, synclock
        int X => LazyInitializer.EnsureInitialized<int>(ref _, ref _, ref _, () => 1);

    
        static T Z<T>(int a) => B.Cache(a, ref _, ref _);  //generates static fields for parameters: cache, lck


        string Y
        {
            get => B.GetterSetter(default, ref _,  true);  // generate backing field  
            set => B.GetterSetter(value, ref _ ,  false);  // generate backing field  
        }
    }

    class B
    {
        public static T Cache<T>(int x, ref Dictionary<int, T> cache, ref object lck)
        {
            T calculate(int z) { ...}
            lock (lck)
            {
                if (cache.TryGetValue(x, out var v))
                {
                    return v;
                }
                else
                {

                    var retval = calculate(x);
                    cache.Add(x, retval);
                    return retval;
                }
            }

        }
        public static string GetterSetter(string value, ref string backing,  bool isGetter)
        {
            static void OnPropertyChanged(string v)
            {
                    ...
            }


            if (!isGetter)
            {
                if (value != backing)
                {
                    backing = value;
                    OnPropertyChanged(value);
                }
            }
            return backing;
        }
    }

I find it much easier to read like that!

Thanks

Here is my answer #4005 (reply in thread)

[YairHalberstadt]

Did you reply to the correct comment? I just requested that you syntax highlight your code.

[YairHalberstadt]

Which I see you've now done. Thanks!

[mstaros]

Which I see you've now done. Thanks!

Thank you) Actually I was going to answer to another your comment-about comparisons with Kotlin delegate properties proposed here)

[mstaros]

This is more or less a dupe of #140, which is championed. The difference is that proposal looks to repurpose the contextual field keyword to refer to this automatic backing field if no other identifier by that name is in scope.

No, you can generate any number of fields here. Not just one predefined field. Which is not enough in general case.

[HaloFour]

@mstaros

Not just one predefined field. Which is not enough.

I see, so you're proposing that each _ refers to a different auto-generated field? How would you refer to the same field twice then?

Coming from languages like Scala that has functionality like this with lambda arguments I can state that the behavior of a discard acting like an incrementing series of values is incredibly confusing and a source of bugs.

[mstaros]

@mstaros

Not just one predefined field. Which is not enough.

I see, so you're proposing that each _ refers to a different auto-generated field? How would you refer to the same field twice then?

Coming from languages like Scala that has functionality like this with lambda arguments I can state that the behavior of a discard acting like an incrementing series of values is incredibly confusing and a source of bugs.

The fields are autogenerated and are used only inside the generating methods. No external references to them. And this is done on purpose.

[HaloFour]

The fields are autogenerated and are used only inside the generating methods. No external references to them.

Which is what makes it incredibly difficult to see what is going on.

[mstaros]

The fields are autogenerated and are used only inside the generating methods. No external references to them.

Which is what makes it incredibly difficult to see what is going on.

Just look inside the method code) Only one place.

[HaloFour]

That method could be anywhere, including other assemblies.

[mstaros]

That method could be anywhere, including other assemblies.

But if you are using the method from the different assembly -you know already what it does.

[HaloFour]

I have to disagree, and if having ref _ anywhere within a method automatically turn into an implicitly typed and anonymously named field in the current class would be a very surprising behavior with unexpected side effects. That would mean that ref _ and out _ have very different semantics.

[mstaros]

I have to disagree, and if having ref _ anywhere within a method automatically turn into an implicitly typed and anonymously named field in the current class would be a very surprising behavior with unexpected side effects. That would mean that ref _ and out _ have very different semantics.

Can you give any example please? how anonymous field not reachable from outside the method call can give a side effect that user is not aware of? A few lines of code if possible

[333fred]

Can you give any example please? how anonymous field not reachable from outside the method call can give a side effect that user is not aware of?

Because the result from the previous call is stored in the class. This is not how discards generally work: the results are completely unobservable. Even in the current method. This would be highly confusing.

[mstaros]

Can you give any example please? how anonymous field not reachable from outside the method call can give a side effect that user is not aware of?

Because the result from the previous call is stored in the class. This is not how discards generally work: the results are completely unobservable. Even in the current method. This would be highly confusing.

I have updated the proposal with a new syntax-with slot keyword and also fields(arguments) can have aliases now. But absent alias still is denoted by _ . If interpret discards as something unobservable.

[mstaros]

Can you give any example please? how anonymous field not reachable from outside the method call can give a side effect that user is not aware of?

Because the result from the previous call is stored in the class. This is not how discards generally work: the results are completely unobservable. Even in the current method. This would be highly confusing.

ok, the syntax could be tweaked , it can be another symbol at your wish . It is the least important point for now.

[HaloFour]

The use case still feels much better solved by either #133 or #140.

public int SomeValue {
    var cache = new Cache<int>(SomeExpensiveCalculation);
    get => cache.Value;
}

public string Name {
    get;
    set => NotifyOnChanged(ref field, value);
}

[mstaros]

The use case still feels much better solved by either #133 or #140.

public int SomeValue {
    var cache = new Cache<int>(SomeExpensiveCalculation);
    get => cache.Value;
}

public string Name {
    get;
    set => NotifyOnChanged(ref field, value);
}

No, it is a subcase. It can repeat only 1 from 3 aforementioned examples.

[CyrusNajmabadi]

I already answered about fields.Its parameters names that define field identity.

In itself this seems highly problematic as that's also not obvious from looking at the code. It also means that changing a parameter name in your code can silently change the meaning of this. i.e. say i have:

get => Foo(out _) + Bar(out _). Changing either of Foo or Bar's first parameter name can dramatically impact what this cod means (i.e. if a field is shared between them, or if it is a fresh field for each.

This is sometimes a problem you get when you want to elide saying as much as possible. Sometimes it's necessary to state these things because otherwise the code simply lacks clarity and is took brittle to normal editing.

[mstaros]

I already answered about fields.Its parameters names that define field identity.

In itself this seems highly problematic as that's also not obvious from looking at the code. It also means that changing a parameter name in your code can silently change the meaning of this. i.e. say i have:

get => Foo(out _) + Bar(out _). Changing either of Foo or Bar's first parameter name can dramatically impact what this cod means (i.e. if a field is shared between them, or if it is a fresh field for each.

This is sometimes a problem you get when you want to elide saying as much as possible. Sometimes it's necessary to state these things because otherwise the code simply lacks clarity and is took brittle to normal editing.

I don't elide anything, sorry. I already stated in proposal that it is about single method call. Read it please before discussion.

[mstaros]

No.the proposal is about single method call.it was stated from the start

[CyrusNajmabadi]

No.the proposal about one method call.it was stated from the start

It may feel discouraging, but part of the lang design process is wondering if a proposal is too specialized. i.e. if you're so narrowly producing a solution for just one case that it's just not worth it. We'll often reject a proposal that has that sort of issue in favor of one that isn't necessarily as terse/simple but which more broadly covers a wider swath of cases.

If the narrow-feature can be a slam dunk (great syntax, easy to understand, solves the 95% case), I would be more amenable to taking it. But if it's much more lke 'so-so syntax, somewhat confusing, and only hits a narrow slice of expressions' then it's far less likely to be picked up.

In hte case here, you're vastly restricting the space where this approach could be used. put another way, with expr-bodied properties we allow any expression today. So i would strongly prefer solutions that do not get in the way of that. I get that for you, the sweet-spot might be one method. But that feels like too strong a limitation to put in place in the language (i.e. we don't do that anywhere else).

[mstaros]

No.the proposal about one method call.it was stated from the start

It may feel discouraging, but part of the lang design process is wondering if a proposal is too specialized. i.e. if you're so narrowly producing a solution for just one case that it's just not worth it. We'll often reject a proposal that has that sort of issue in favor of one that isn't necessarily as terse/simple but which more broadly covers a wider swath of cases.

If the narrow-feature can be a slam dunk (great syntax, easy to understand, solves the 95% case), I would be more amenable to taking it. But if it's much more lke 'so-so syntax, somewhat confusing, and only hits a narrow slice of expressions' then it's far less likely to be picked up.

In hte case here, you're vastly restricting the space where this approach could be used. put another way, with expr-bodied properties we allow any expression today. So i would strongly prefer solutions that do not get in the way of that. I get that for you, the sweet-spot might be one method. But that feels like too strong a limitation to put in place in the language (i.e. we don't do that anywhere else).

I have updated the definition of the field scope and thus managed to remove the limitation. See updated
#4005 (comment)

[CyrusNajmabadi]

It is open for discussion

Of course :) this is part of a healthy discussion on the topic. Effectively, as i weigh a language proposal i end up having to weigh out this stuff. I strongly understand your desire to write less, and to have a brief syntax to solve this issue for yourself. Where things break down for me is that i see this coming with severe issues that worry me.

[mstaros]

No ..your examples about any expression while the proposal is about single call. It is about flexible one liner

[HaloFour]

No.the proposal is about single method call.it was stated from the start

That seems like an unnecessary limitation. Why shouldn't someone be able to use this feature in any expression-bodied member? Or any member?

[mstaros]

Because it is so easy to wrap code in a method to avoid any code repetition.

[mstaros]

I cannot see any big restriction here frankly. One time method wrapper creation versus field definition repetition. We already do method wrappers. When passing things to base constructor for example.

[CyrusNajmabadi]

You would need to create a wrapper mehtod for all places where you had multiple calls (or any sort of more complex expression). i get that you don't think that's a big deal. But now can you see why other s don't think it's a big deal to just have the var ... in the property? In each case, there's a new declaration being made. The benefit of the property-local case is that it's scoped just to the property. With your 'method wrapper' case, now i'm not only making the method, but i'm also cluttering up my type with it.

[HaloFour]

Feels like this is half-way attempting to be delegated properties, but trying to keep the state external which is why it's requiring these automagick ref fields. I'd much rather more exploration with delegated properties (and how they relate to property-scoped fields, if they do). The property could be a struct and define its own internal state that is completely hidden from the consuming property. Building on my example above:

public struct LazyStruct<T> {
    private readonly object sync;
    private readonly Func<T> factory;
    private bool initialized;
    private T value;

    public LazyStruct(Func<T> factory) {
        this.sync = new object();
        this.factory = factory;
    }

    public T Getter() => Lazy.EnsureInitialized(ref value, ref initialized, sync, factory);

    public void Setter(T value) {
        this.value = value;
        this.initialized = true;
    } 
}

// use
public int SomeValue using new LazyStruct<int>(SomeExpensiveCalculation);

// lowered to
private LazyStruct<int> <>SomeValue_delegate = new LazyStruct<int>(SomeExpensiveCalculation);
public int SomeValue {
    get => <>SomeValue_delegate.Getter();
    set => <>SomeValue_delegate.Setter(value);
}

[HaloFour]

@mstaros

It is a pity because you didn't give any single convincible reason in support of this.

It's not my job to convince you. It's your job to convince the language design team. Two such members have already weighed in here that they don't like this approach of automatically generating class fields and wiring them up based on parameter name. Both of those members have mentioned support and interest in delegated properties.

[HaloFour]

1.What about Interlocked methods? Or volatiles.Write? How can you say about all c# third-party libraries that ref parameters are not existent there?))

Not a single one of those methods were written to work with this proposal. Instead you're trying to design your proposal to accidentally work with those methods. There is no contract there, it's a brittle relationship. And yes, I would suggest that the vast majority of cases where a feature like this would be useful which require writing brand new methods. Especially if you want them to be virtual/abstact, in which case you'll have to write them every single time, over and over and over again, leading to massive code bloat and lots of bugs.

Even when i write method it is not code bloat. Insted of putting code into getter I put it into method. Getter is intact. Where have you found the code bloat here?

You're writing more code, that is code bloat.

You came to the structs trying to solve memory issue.

I used structs because structs were appropriate. The fact that they have an identical memory footprint to their constituent fields and that in simple cases they can be elided entirely is a happy benefit.

Yes, but rewrite once per subclass and everything is done

Rewriting wrapping per subclass is code bloat. You made a giant stink about this idea that you'd have to write code for wrappers based on my suggestion, yet somehow this same complaint doesn't apply to your proposal? That's very disingenuous.

[mstaros]

Yes, but I waited for a serious discussion, not statement like that - "almost no methods with ref parameters in all c# libraries in the world" or " you have crafted the proposal for single existent in the world ref method EnsureInitialized". It is not professional at all. I was and and am waiting for professional discussion here..

[mstaros]

1.What about Interlocked methods? Or volatiles.Write? How can you say about all c# third-party libraries that ref parameters are not existent there?))

Not a single one of those methods were written to work with this proposal. Instead you're trying to design your proposal to accidentally work with those methods. There is no contract there, it's a brittle relationship. And yes, I would suggest that the vast majority of cases where a feature like this would be useful which require writing brand new methods. Especially if you want them to be virtual/abstact, in which case you'll have to write them every single time, over and over and over again, leading to massive code bloat and lots of bugs.

Even when i write method it is not code bloat. Insted of putting code into getter I put it into method. Getter is intact. Where have you found the code bloat here?

You're writing more code, that is code bloat.

You came to the structs trying to solve memory issue.

I used structs because structs were appropriate. The fact that they have an identical memory footprint to their constituent fields and that in simple cases they can be elided entirely is a happy benefit.

Yes, but rewrite once per subclass and everything is done

Rewriting wrapping per subclass is code bloat. You made a giant stink about this idea that you'd have to write code for wrappers based on my suggestion, yet somehow this same complaint doesn't apply to your proposal? That's very disingenuous.

The gist of proposal is that it does not need methods to be specifically designed for it. That is one of the main point. You just use them as is.

it is not rewriting wrapper for subclass. It is virtual method rewrite. You don't need to change references to it. That is the huge difference with your solution. Can you see why virtual methods are in use at all? If yes-you should understand my point. I am not going to lecture you on differences between copypaste of all references and rewrting of virtual methods.

[CyrusNajmabadi]

Agreed

Ok. So just to make sure. We can table all discussions about size at this point? And we're both onboard with the idea that any proposal involving field generation can be represented with a struct containing those fields with the same runtime behavior and performance?

I just want to make sure that that's understood as there was a lot of argument against that earlier. Thanks!

[mstaros]

No..you have 100 similar properties. What is better-to create method once or to copy paste the fields and tje logics? What is better when you want to refactor them all tomorrow? Then day after tomortow?

[mstaros]

What is better-to create method once

I could say the same for your approach :) You could have to make 100 helper methods to do the wrapping as you specified.

What is better when you want to refactor them all tomorrow?

IMO, the property-field approach is the better way.

if you have 100 different properties and no similar properties among them ( which is quite rare, but still may be, who knows) - ok, just encapsulate fields. Where is the contradiction?

[HaloFour]

if you have 100 different properties and no similar properties among them

Then you have no need for code reuse since the properties aren't repeating anything and none of these proposals are necessary or appropriate.

[mstaros]

if you have 100 different properties and no similar properties among them

Then you have no need for code reuse since the properties aren't repeating anything and none of these proposals are necessary or appropriate.

Here I have to disagree. You still need encapsulate fields into properties. It is not about code reuse. Not autogenerate may be, but encapsulate for sure.

[HaloFour]

I don't see an issue with that. With your proposal you need to wrap every property in a separate method with a ref parameter. You'd already be writing more code than if you ignored all of these proposals and wrote your property using C# 1.0 syntax.

[mstaros]

You misunderstood -vice versa I told that fields could be encapsulated manually in the case

[CyrusNajmabadi]

@mstaros I've moved this to be a discussion to help with all the back and forth. in general, we want to reserve issues for the point at which we have a strong design we can write up and move through the rest of the design/impl process. Thanks! :)

[YairHalberstadt]

@mstaros

Perhaps we should start over.

The relative benefits of this proposal over delegated properties are irrelevant. All discussion about how good this proposal is or isn't is irrelevant.

As it is it wont be implemented, simply because it is at odds with the rest of C#.

Language design is incremental. You take something that already exists, and stretch it a bit further. You think of a new way to do something that fits in best with how things are already done. That makes it much easier for people to learn the language and new features, since everything fits into how you expect.

This particular proposal doesn't do that:

1. _ already has a meaning in C#. It means a discard. It means a value that is ignored. It does not mean, implicitly create a field, and giving it that second meaning is a huge change from it's first meaning.
2. Relying on compiler generated names doesn't exist in the language. In C#, either a name is explicit, or it's an implementation detail. Here names are implicit, but decide whether or not two parameters refer to the same field.
3. In C# reusable bits of functionality focus on ways to encapsulate state from the user. This feature explicitly rejects the possibility of encapsulating state, and forces the consumer to control it.

So this might be a perfect feature, in some other language. In C#, as, is, it won't happen.

Your problem though is definitely appreciated, and is a real problem.

The most productive way this conversation can go is for us to work together here to see how we can modify your proposal to make it something more C#y that might be considered. The least productive will be to argue over whether or not it's better than delegated properties.

[mstaros]

and poor code quality.

While I'm finding this discussion interesting I would ask you try to limit this sort of editorializing. It's not really helping and it feels extremely dismissive. I, for one, do not think using structs in this manner is poor code quality. You may think differently, and you're free to provide solid arguments defending that position. However, outright dismissing it without actual justification just make me feel like you're unwilling to consider any other viewpoints here.

Agree. I will add a reasoning then after every such statement. Actually I was doing this in order to shorten my answers only.

[CyrusNajmabadi]

Yes, but in this particular case composition will bring you nothing but additional coding.

It also brings reusability. It also brings the ability to use all the other facets of the language to bear. The way I see it is that this proposal is good for an extremely small slice of cases. And it introduces many concepts that feel decidedly different from c# and which only work for that small handful.

It has extreme brevity going for it, but that's about it.

Other proposals provide much more flexible and powerful mechanisms to solve this problem space. They range in brevity from extremely brief to slightly brief.

Given the extremely narrow set of cards this world with with, I can't see myself championing this. If you can make a convincing argument that this would work for far more than those, that would help.

I recommend going and looking at previous discussions where people wanted it to be easier to avoid having to create a field. If you can take those examples provided and show how your proposal addresses all those cases, that would be a good argument in favor of this. However, right now I'm not seeing it. It seems like this just solves for a tiny set if cases that only you are adding about, and didn't solve for the hundreds of other cases the rest of the community has asked for.
Thanks!

[mstaros]

It's a little extra code yes, but it's write once use everywhere. On the other hand using inheritance, is slightly less code, but can only be used by classes that inherit from the base class - i.e. not structs, or anything which already has a base class, or which is already released (since adding a base class is a breaking change I think). That's a pretty good argument for composition.

The difference is that with delegate properties composition and extra code is a must. If you use structs for the better performance. While with methods you quite often will happily avoid this.

[mstaros]

Yes, but in this particular case composition will bring you nothing but additional coding.

It also brings reusability. It also brings the ability to use all the other facets of the language to bear. The way I see it is that this proposal is good for an extremely small slice of cases. And it introduces many concepts that feel decidedly different from c# and which only work for that small handful.

It has extreme brevity going for it, but that's about it.

Other proposals provide much more flexible and powerful mechanisms to solve this problem space. They range in brevity from extremely brief to slightly brief.

Given the extremely narrow set of cards this world with with, I can't see myself championing this. If you can make a convincing argument that this would work for far more than those, that would help.

I recommend going and looking at previous discussions where people wanted it to be easier to avoid having to create a field. If you can take those examples provided and show how your proposal addresses all those cases, that would be a good argument in favor of this. However, right now I'm not seeing it. It seems like this just solves for a tiny set if cases that only you are adding about, and didn't solve for the hundreds of other cases the rest of the community has asked for.
Thanks!

Can you please give me here any example to solve now? Because I been told here that I craft the examples on the purpose.. Anything that is interesting for you? something that you think is not solvable with this method but works well with delegate property?

[CyrusNajmabadi]

something that you think is not solvable with this method

any calls that want to store state in fields, but don't call into ref-parameter-taking-methods.

As i understand, in your version, you would create a new method for this that had ref-parametres where you would place all the logic.

The downsides of this, as mentioned before are:

1. this feels decidely un-c#y. i.e. having fields be implicitly created in this fashion is def not really aligned with anything else we've shipped.
2. you now need a method cluttering your type. This actually goes against goals we have with properties which is more narrowly scope things. i.e. my idea with most properties is that, outside of composition scenarios, all logic/state be kept within the property itself. This way people can tell exactly what is needed only for the property, and anything outside of the property should be either used for other functionality in the type.

[mstaros]

about special symbol... again off the head.. what about ref #field for example? instead of ref _

[YairHalberstadt]

out var creates a local. It would be very odd for ref var to create a field.

[mstaros]

out var creates a local. It would be very odd for ref var to create a field.

ok.. so ref #field.. with sharp #.... or ref slot or may be ref <parameterName>:#slot
I believe that the version with parameter name is most readable.

[CyrusNajmabadi]

ok.. so ref #field

Or... how about: int newFieldName = ... :)

We already have great syntax for defining a symbol (including providing a type if that's desired). It's short, sweet, simple and intuitive. It scopes cleanly and would feel very natural coming from any previous version of C#. It works for all scenarios you've listed, and the vast majority of other scenarios we've identified. The only downside in comparison is that it's not as brief. But it makes up for that by

1. handling many more cases.
2. Not requiring defining other methods outside of the property
3. being scoped well.
4. feeling like a natural fit to the language.

[mstaros]

ok.. so ref #field

Or... how about: int newFieldName = ... :)

We already have great syntax for defining a symbol (including providing a type if that's desired). It's short, sweet, simple and intuitive. It scopes cleanly and would feel very natural coming from any previous version of C#. It works for all scenarios you've listed, and the vast majority of other scenarios we've identified. The only downside in comparison is that it's not as brief. But it makes up for that by

1. handling many more cases.
2. Not requiring defining other methods outside of the property
3. being scoped well.
4. feeling like a natural fit to the language.

You mean property-scoped fields? What are you talking about? Property-scoped fields lack templating. We've discussed it already in details.

[CyrusNajmabadi]

You mean property-scoped fields?

Yes.

Property-scoped fields lack templating.

I don't know what templating means.

We've discussed it already in details.

Can you point out where "templating" has been discussed? Looking through the thread, this is the first time i've even seen the term mentioned.

[mstaros]

int A=>M( ref_ ) + something(1);
int B=>M( ref_ ) + whoknows(2);

You need in general two delegate property wrappers here. While one method M is enough.

[mstaros]

Well what do you think is more user friendly:

        string A
        {
            get => Getter(ref slot x);
            set => Setter1(ref slot x, default, Setter2(ref slot  x, value));
        }

string A using Setter1, Setter2;

The first isn't at all intuitive to work out what to write. It requires you to understand how Ticket work and how to pass one to another property.You have to know which getter to use with which setter. You have to know which ref parameters should have the same name and share a backing field, and which should have a different name and not. And all it really saves you, is this:

        string A
        {
            string x;
            get => Getter(ref x);
            set => Setter1(ref x, default, Setter2(ref x, value));
        }

It's actually more characters of code than what you could write today!

One question that is still open in the case- templating of cached (memoized) methods. They left totally uncovered by these property-scoped fields. And there should be uniform approach. I think method-scoped fields could solve it.

[CyrusNajmabadi]

i don't know what you mean by "templating".

[mstaros]

i don't know what you mean by "templating".

templating (in this case at least) means self-encapsulated entity with logic and fields. The whole discussion was about that I believe)

[CyrusNajmabadi]

i honestly don't have any idea what that woul dhave to do with 'cached (memoized) methods'. This entire discussion (and property fields) is about properties, not methods. Why would caching/memoizing methods be part of that?

[mstaros]

So we had different discussions here). Method were stated as target in the proposal from the very beginning. Proposal contains example of their usage. Actually it is about encapsulation of caching fields inside the methods also. About memorization. When you don't want to use closures and delegates for this. The gist of proposal is to do both things in uniform way.

[mstaros]

You asked me not to expess negative opinion on subjects without supporting arguments ..but you yourself keep doing it the second day in a row..including this comment about extremely narrow scope.. you expressed the bare opunion may be 100 times..and never answer when i ask for concrete examples..is it ok?

[mstaros]

You misread the proposal, I am afraid. It is not about use-case when a programmer is going to use expression-bodied member as a syntax sugar. Expression-bodied is used here as a definition of property or method actually. Exactly as delegate properties mean definition only. Both of them have scope of member definition in general.

@mstaros, please go back and read what I wrote again, for you clearly did not read it in full.

You asked what @CyrusNajmabadi meant by saying that your proposal had narrow scope; that was the question I was answering.

Of course I got that it was your answer and gave you back my explanations.

[mstaros]

1. you introduce another method, but this method now sits in your class cluttering it's name space.

You could introduce this method in a separate static class.

By the way I have changed the syntax as we discussed yesterday. With slot keyword. Now argument can be an alias . It is an alias for the field.

[mstaros]

You misread the proposal, I am afraid. It is not about use-case when a programmer is going to use expression-bodied member as a syntax sugar. Expression-bodied is used here as a definition of property or method actually. Exactly as delegate properties mean definition only. Both of them have scope of member definition in general.

@mstaros, please go back and read what I wrote again, for you clearly did not read it in full.

You asked what @CyrusNajmabadi meant by saying that your proposal had narrow scope; that was the question I was answering.

I cannot expand more on your answer because it just states that people don't need autogenerated fields in type members and templates for them. Without any explanations. Just a statement. It is difficult to argue with bare statements you see. May be you can explain then why do people use delegate properties in Kotlin at all? why Kotlin team has developed it? . or why do companies develop large AOP frameworks to handle logging and notification systems? to name a few ...

[CyrusNajmabadi]

By the way I have changed the syntax as we discussed yesterday. With slot keyword. Now argument can be an alias . It is an alias for the field.

I don't know why we need this new syntax when there is an existing proposal with totally reasonable syntax that supports a superset of these cases. You keep pushing the ref parameter has some sort of syntax to make a field with a particular name. However, that seems to be something non-beneficial.

If i want a field with a particular name, here's a really good syntax for it:

int foo;

It fits C# syntax everwhere for declaring a variable. It does not call into question what the type should be inferred as. It does not call into question waht the name should be inferred as. The scope is nicely narrowed down to just the property. It does not require reformulating all the operations we want to perform using ref-parameters (in itself an extremely niche feature).

In essence, i'm basically saying: your proposal is tying something that we want to be very normal (scoped fields), to something very abnormal (ref parameters). You keep hitching what you want to something that makes your entire proposal feel very odd to the rest of C#.

You keep on trying to come up with new syntax around this. However, it's not the syntax (alone) that's the problem. It's that it's somehow assocaited with ref-parameters. That's the part that just doesn't resonate or make any connection for me. In no way would i ever think "if i want some state for my property body... i shoudl be expressing that through the use of ref-params".

I would recommend you reformulate your proposal with that piece as i see it as almost certainly something that would not come to pass. Put more simply:

1. i wouldn't myself champion this in the LDM.
2. even playing devil's advocate, i literally do not know how i would argue that this should be done to the rest of the LDM. With other proposals i can at least understand how to defend it, even if i don't personally like it. With this one, i actually can find no way to do that.

I hope this helps provide some clarity on where i currently see the impasse. Thanks!

[mstaros]

By the way I have changed the syntax as we discussed yesterday. With slot keyword. Now argument can be an alias . It is an alias for the field.

I don't know why we need this new syntax when there is an existing proposal with totally reasonable syntax that supports a superset of these cases. You keep pushing the ref parameter has some sort of syntax to make a field with a particular name. However, that seems to be something non-beneficial.

If i want a field with a particular name, here's a really good syntax for it:

int foo;

It fits C# syntax everwhere for declaring a variable. It does not call into question what the type should be inferred as. It does not call into question waht the name should be inferred as. The scope is nicely narrowed down to just the property. It does not require reformulating all the operations we want to perform using ref-parameters (in itself an extremely niche feature).

In essence, i'm basically saying: your proposal is tying something that we want to be very normal (scoped fields), to something very abnormal (ref parameters). You keep hitching what you want to something that makes your entire proposal feel very odd to the rest of C#.

You keep on trying to come up with new syntax around this. However, it's not the syntax (alone) that's the problem. It's that it's somehow assocaited with ref-parameters. That's the part that just doesn't resonate or make any connection for me. In no way would i ever think "if i want some state for my property body... i shoudl be expressing that through the use of ref-params".

I would recommend you reformulate your proposal with that piece as i see it as almost certainly something that would not come to pass. Put more simply:

1. i wouldn't myself champion this in the LDM.
2. even playing devil's advocate, i literally do not know how i would argue that this should be done to the rest of the LDM. With other proposals i can at least understand how to defend it, even if i don't personally like it. With this one, i actually can find no way to do that.

I hope this helps provide some clarity on where i currently see the impasse. Thanks!

Yes. Property-scoped fields seem to give almost exactly the same effect as slots but with familiar syntax. Agree. One unresolved thing though is how to cover in this case templating of the method-caching. Slots cover them both in uniform way. What about introducing method-scoped fields then?