Allow child classes to add a setter for covariant overridden properties

[ethanresnick]

I.e., I'm proposing that things like this should be allowed:

class Person { 
  public virtual Organization Employer { get; }
}

class Teacher : Person {
  public override School Employer { get; set; } // child class cannot add `set` modifier here
}

class Nurse : Person {
  public override Hospital Employer { get; set; } // ditto
}

I understand why Person cannot include a set accessor for Employer (wouldn't be type safe) but, given that restriction, it seems useful (and I think safe?) to allow the child classes to add the accessor. In this example, it seems like both the covariance on the property type and being able to set the property's value on the child types' instances are valuable.

[theunrepentantgeek]

If you change the definition of Teacher to this:

class Teacher : Person {
  public override Organization Employer { get; set; }
}

then you still get a compiler error, albeit a different one:

error CS0546: 'Teacher.Employer.set': cannot override because 'Person.Employer' does not have an overridable set accessor

So, while the original error message may not be ideal, it is certainly consistent.

If the language was modified to allow a set accessor to be added in the covariant case, it would also need to be modified to allow it in the non-variant case.

I strongly suspect there are very good reasons why this isn't currently supported, starting with the potential to violate Liskov substitution.

[spydacarnage]

Personally, I see inheriting from an abstract class and implementing an interface as different things.
Inheritance implies that the child object is the same as the parent, but more.
An interface can be seen almost as a way to view an object, like a lens - often a cut-down version of its full capabilities.

[JustNrik]

I agree with spyda, inherance and contracts are very different semantically. Inheritance is a is a relationship, while contracts are has a relationship, the interface doesn't really care whatever else you have in your class as long as you have what it requires, that said, if you implement a readonly property from an interface, it only cares if the property has a getter, it doesn't care if the class that implements the interface added a setter or init because the contract is already fullfilled. With inheritance this is a whole different story, if you have a readonly property, you expect the children to have the same readonly property because both are semantically the same object, the children is just an extension of the parent, not a completely different object from it.

[jnm2]

A get-only property does not imply immutability, even if it's not virtual.

[ethanresnick]

@theunrepentantgeek I agree that what I’m asking for here applies just as much in the case where the child class's property is of the same type, so I’m going to close this in favor of #1568, which I appreciate @svick pointing out.

As for LSP, I think I agree with @JMN2 and @svick that there's not enough signal from a readonly property for a reader to reasonably assume immutability; consider that, in my example, I definitely want Employer to be mutable -- it just has to be mutable only at the child class level in order to be type safe. [That's maybe the sense in which this proposal is more important in the covariant override case, since the parent class really can't just add a setter.]

More generally, a language like C# (that doesn't have built-in functionality for checking pre- and post-conditions) really can't do much to prevent LSP violations. Consider that it’s already perfectly legal for a child class to make a parent's readonly property mutable by defining a new method, as in:

class Teacher : Person {
  private School _employer;
  public override School Employer { get => _employer; }
  public void SetEmployer(School it) => _employer = it;
}

So I think we're at a point where the burden to follow LSP is pretty clearly already on authors, and we shouldn't worry much about users violating LSP when considering new features. Of course, that's not a blanket rule -- if a feature really is gonna encourage LSP violations that wouldn't happen otherwise, that's worth taking into account -- but allowing child properties to add setters doesn't strike me as qualitatively worse than the many existing ways that LSP can be violated.

[theunrepentantgeek]

Keep in mind that I wrote

Off the top of my head - and this is nothing more than "what immediately came to mind" - ...

The LSP issue was simply the first thing that came to mind, and was simply an example.

Any time you change behaviour in a sub-type in ways that have not been anticipated by the author of the base type you can (and likely will) run into grief.

That said, if #1568 goes ahead, I do hope it allows for covariant implementations as well.