Proposal: Allow redundant accessibility modifiers

[Lehonti]

Currently, doing this:

private int SomeProperty { get; private set; }

Causes this compilation error:

The accessibility modifier of the 'Foo.SomeProperty.set' accessor must be more restrictive than the property or indexer 'Foo.SomeProperty'

But this would actually be useful when creating a property that you may, sometime in the future, change the accessibility of (lots of reasons you may want to do this). In the example above, this would be a way of saying "even if you turn this property from private to protected, the setter should remain private".

[jnm2]

@Lehonti Can you give examples of what sort of problems are cropping up due to not having this ability?

[scottdorman]

@jnm2 One possible scenario for this could be when changing a private property to a protected one. The property should still only be set by the owning class, but the value should be accessible to derived classes. Today, the only way to write the property is

private int SomeProperty { get; set; }

As soon as you change it to

protected int SomeProperty { get; set; }

any derived class now has the ability to set the value, which isn't what you wanted/intended/desired.

By writing it as

private int SomeProperty { get; private set; }

you can guarantee (in a loose sense at least) that changing the property to protected won't change the accessibility of the setter.

Yes, I realize this is a somewhat contrived example, but it still seems valid. The "outer" accessibility modifier is "shorthand" for writing

int SomeProperty { private get; private set; }

To expand the example some, consider a class that, when originally written, had no known need to be subclassed. As the code matures, there is now a need to subclass it but there is a property that the subclasses need access to. That's when the property accessibility needs to change from private to protected, but the base class is the only thing that should be setting it (maybe through a constructor parameter). That's a valid scenario, and I'm sure we've all written a property at one time or another following that same rough pattern.

[theunrepentantgeek]

One possible scenario for this could be when changing a private property to a protected one.

If I have this property:

private int SomeProperty { get; set; }

and I want to make it protected, I've got a choice.

I could make it this:

protected int SomeProperty { get; set; }

or I could make it this:

protected int SomeProperty { get; private set; }

I still have that choice, even if my starting point is

private int SomeProperty { get; private set; }

I don't see how allowing a redundant modifier improves things. If I'm a diligent developer, there's no difference to the final result because I'll make the correct, informed, choice. If I'm not, then sure as eggs I'm going to mechanically change both visibilities mechanically because I'm not thinking:

protected int SomeProperty { get; protected set; }

I don't think language changes to defend against incompetent maintainers are ever going to actually work.

[scottdorman]

I was only trying to point out a possible scenario where this could help. I never said I agreed with it.