[Proposal] Allow overriding single accessor properties with multiple accessors

[MrJul]

Copied and improved from the original issue dotnet/roslyn#9482

---

Description

Currently, a virtual or abstract property having a single get or set accessor can't be overridden with a property having both accessors. This proposal removes this limitation.

How the override is written doesn't matter: explicit accessors as well as auto-properties are permitted.

The following code is now valid:

public abstract class Base {
    public abstract string Prop1 { get; } // can also be virtual
    public abstract string Prop2 { set; } // can also be virtual
}

public class Derived : Base {
    public override string Prop1 { get; set; } // no more CS0546
    public override string Prop2 {
        get { ... } // no more CS0545
        set { ... }
    }
}

Why

1. This kind of construct is already allowed for interfaces: a read-only or write-only property declared in an interface can be implemented by a read/write property. This proposal makes this valid for classes to avoid disparities.
2. It's a valid CLR construct. Lately, the C# compiler had other proposals to expose existing CLR features to C# (notably private protected).
3. Because it's useful ;) Here's a sketch of the piece of code that made me write this proposal in the first place:

public class RenderBlock {
    public abstract int Width { get; }
}

public class AutoSizeText : RenderBlock {
    public string Text { get; set;}
    public override int Width => CalculateWidthFromText();
}

public class Rectangle : RenderBlock {
    public override int Width { get; set; }
}

Of course I could have added a SetWidth() method, but this didn't feel right.
(Note: as with any code problem, this can be - and has been - solved differently: let's not discuss that, it's just a sample.)

Impact

CLR

The CLR already allows this. As far as it's concerned, the two accessors are separate methods, and the override/abstract/virtual modifiers are applied on each method, not on the property itself.

I've compiled a code equivalent to the sample above using ilasm, verified that it's valid according to peverify, and ran it successfully.

Compiler

The following compiler errors are removed:

• CS0545: cannot override because 'property' does not have an overridable get accessor
• CS0546: cannot override because 'property' does not have an overridable set accessor

I've already made some changes in a private branch, those errors are pretty straightforward to remove. No changes are needed in code generation. I'll add proper tests and send a pull request if this proposal is accepted.

Compatibility

The current compiler and tooling can already handle assemblies using those overrides.
Since it's always been a valid construct at the metadata level, I suspect pre-Roslyn versions of the compiler have no problem handling this, but I've not tested them.

Implicit implications

The newly added accessor is automatically marked as virtual, unless the property or its containing class is sealed. This seems like a sensible choice, since override already implies virtual.

Spec change

In the classes specification, the following text:

If the inherited property has only a single accessor (i.e., if the inherited property is read-only or write-only), the overriding property must include only that accessor.

is replaced by:

If the inherited property has only a single accessor (i.e., if the inherited property is read-only or write-only), the overriding property must include that accessor, and can optionally define another accessor. If a new accessor is introduced by the overriding property declaration, it is automatically considered virtual, unless the property is sealed.

[HaloFour]

The accessor methods are considered separate, but the property metadata isn't. If a type tries to declare an overridden property and point an accessor to a method in the base class that type will not verify.

[MrJul]

@HaloFour Am I missing something here? The newly property is adding an accessor, not removing one, so there won't be any case of a derived property pointing to an accessor in the base class.

[svick]

@HaloFour You don't have to point it to a method in the base class, you point it to the method that's in the derived class. That's already what happens when you override a property and I don't see why would it cause any issues with this proposal.

In other words, this code:

public abstract class Base
{
    public abstract string Prop { get; }
}

public class Derived : Base
{
    public override string Prop
    {
        get => null;
        set {}
    }
}

would produce the following IL, which peverifies fine.

.assembly extern mscorlib { }
.assembly lib { }

.class public abstract auto ansi beforefieldinit Base
       extends [mscorlib]System.Object
{
  .method public hidebysig newslot specialname abstract virtual 
          instance string  get_Prop() cil managed
  {
  }

  .method family hidebysig specialname rtspecialname 
          instance void  .ctor() cil managed
  {
    ldarg.0
    call       instance void [mscorlib]System.Object::.ctor()
    ret
  }

  .property instance string Prop()
  {
    .get instance string Base::get_Prop()
  }
}

.class public auto ansi beforefieldinit Derived
       extends Base
{
  .method public hidebysig specialname virtual 
          instance string  get_Prop() cil managed
  {
    ldnull
    ret
  }

  .method public hidebysig specialname virtual 
          instance void  set_Prop(string 'value') cil managed
  {
    ret
  }

  .method public hidebysig specialname rtspecialname 
          instance void  .ctor() cil managed
  {
    ldarg.0
    call       instance void Base::.ctor()
    ret
  }

  .property instance string Prop()
  {
    .get instance string Derived::get_Prop()
    .set instance void Derived::set_Prop(string)
  }
}

[HaloFour]

@svick @MrJul

Yeah, I think I read the proposal backwards, where you're looking to override a single accessor from a base class that declares both as virtual. That's what I get for skimming proposals on my phone.

[Joe4evr]

As I've posited in the related thread, an alternative syntax might be to require new in front of the derived-added accessor, to indicate that that accessor method isn't related to the base class. This would only be allowed if that accessor does not exist on the base's virtual property, otherwise a compiler error occurs. Adding the second accessor to a single-accessor virtual property is already a breaking change either way, so compat-issues with this approach would be moot.

[MrJul]

@Joe4evr That would give us a different syntax between interfaces and classes when implementing/overriding a single-accessor property with a two-accessors property.

Furthermore, currently new is used only to hide base members. There's even a warning CS0109 when new isn't hiding any existing member, so using it here would trigger this warning, or would be a special case, which seems inconsistent imho.

[anreton]

I came across this restriction many times, please consider its implementation and inclusion in the language.

[Thaina]

I would like to have this feature too

Also is it possible to separately define abstractness of get and set ?

class A
{
    public int X { get => x; virtual set => x = value; } // cannot override get
    public bool Condition { abstract get => x; } // may or may not implement set
    public abstract bool Condition { get => x; } // cannot implement set, current behaviour
}

[mythjuha]

Have needed this a couple of times. Usually ended up writing the getter in the base class and throwing notsupportexceptions. But that doesn't give you much compiler/design time validation/security/error checking.

[ethanresnick]

This should also apply when the overridden property has a covariant type, as discussed in #5179. In that case, the ability to add a setter in the child class may be especially important, since there's no way to define even a dummy setter in the parent class (that just throws) without the compiler complaining about a legitimate type safety issue.

[hdpotter]

I've also been burned by this restriction, and would love to see the suggested fixes implemented.

[momvart]

It's surprising that with this many duplicates and upvotes no official has responded yet. I would like to know if there is a serious problem with it.

[TonyValenti]

I'd love to have this too.

[ds5678]

It's surprising that with this many duplicates and upvotes no official has responded yet. I would like to know if there is a serious problem with it.

Agreed. Can we get some LDT attention on this?

[dnl-blkv]

+1, let's make it a reality, folks

[ceztko]

I periodically stumble in this limitation as well. It would be very interesting to take care of it as well after finally covariant return types were allowed in overrides.

[ThaDaVos]

So the corresponding issue is closed as it's moved to a discussion, duplicates get closed too - but still no answer here - any update?

[CyrusNajmabadi]

There is no update on this.

[sab39]

Do proposals like this get periodically triaged to see if anyone on the team is interested in championing them?

[CyrusNajmabadi]

@sab39 yes.

[Charlieface]

@CyrusNajmabadi
So how does that triaging process work? Is there any way to influence it, eg via votes? Is there any way to see when triaging will happen?

[kaleidocore]

I believe the community is still waiting for this one? It's rather confusing that it works for interfaces but not for classes.