Questions for semi-auto properties

[Youssef1313]

Moving discussion from #57012 (comment).

---

Comment by @Youssef1313:

There are interesting scenarios around overriding virtual properties.

public class Base
{
    public virtual int P1 { get; set; }
    public virtual int P2 { get; set; }
    public virtual int P3 { get; set; }
    public virtual int P4 { get; set; }
    public virtual int P5 { get; set; }

    public virtual int P6 { get => 0; set { } }
}

public class Derived : Base
{
    // no error.
    public override int P1 { get => 0; }
    
    // This produces Auto-implemented properties must have get accessors.
    // However, per the spec updates, a set-only with semicolon is allowed.
    // Should this now produce an error similar to ERR_AutoPropertyMustOverrideSet?
    public override int P2 { set; }

    // This synthesizes a sealed setter. Make sure we have this behavior for semi-auto.
    public sealed override int P3 { get => 0; }

    // Auto-implemented properties must override all accessors of the overridden property.
    public override int P4 { get; }

    // Will this be allowed? It's not allowed for old-style auto properties (see P4).
    public override int P5 { get => field; }

    public override int P6 { get => field; }

    public Derived()
    {
        // P6 looks like a property that's assignable through backing field.
        // But this shouldn't be the case due to the inherited setter.
        // We should use 'GetOwnOrInheritedSetMethod' for the logic of assignability through backing field.
        // Add a test to confirm that.
        P6 = 10;
    }
}

Do these scenarios have clear answer as to what's the expected behavior? Are there any that needs to be discussed in LDM?

cc @AlekseyTs @333fred @CyrusNajmabadi

---

Comment by @AlekseyTs:

per the spec updates, a set-only with semicolon is allowed.

Could you add a quote from the relevant portion of the spec?

Should this now produce an error similar to ERR_AutoPropertyMustOverrideSet?

Please include exact wording of the message.

// Will this be allowed? It's not allowed for old-style auto properties (see P4).

We probably should treat this as a property with a user provided body. Presence of the field keyword probably shouldn't make any difference.

[Youssef1313]

Could you add a quote from the relevant portion of the spec?

https://github.com/dotnet/csharplang/blob/main/proposals/semi-auto-properties.md

+ An automatically implemented property (or ***auto-property*** for short), is a non-abstract non-extern
+ property with either or both of:
+ 1. an accessor with a semicolon-only body
+ 2. usage of the `field` contextual keyword ([Keywords](lexical-structure.md#keywords)) within the accessors or
+    expression body of the property. The `field` identifier is only considered the `field` keyword when there is
+    no existing symbol named `field` in scope at that location.

---

Please include exact wording of the message.

Auto-implemented properties must override all accessors of the overridden property

[Youssef1313]

Closing. Will open this as multiple issues, each is focused on a single scenario.

[Youssef1313]

@AlekseyTs Should I open in csharplang or here?

[AlekseyTs]

Should I open in csharplang or here?

@333fred Do you have any preference? I don't.

[333fred]

Prefer opening questions for LDM in csharplang.

[Youssef1313]

I'm not sure if they need to be discussed in LDM or the answer is simply clear. But let me open it there.

[Youssef1313]

dotnet/csharplang#6077
dotnet/csharplang#6076

#61038