Do adding properties to an interface prevent creating private/protected "set" in derived types?

Question

Edit: It turns out I missed something obvious, but I'm going to leave the question open in case someone else makes the same obvious mistake. Thanks to those who pointed it out See bottom for explanation.

Is it possible to have a non-public set on a property that is overriding an interface property?

Perhaps I'm having a stupid moment, but it seems to me that having a property defined in an interface implicily requires that no deriving class may provide any non-public set for said property.

Example:

interface IField
{
    bool IsValid { get; }
}

... and since interface properties may not have accessibility modifiers means that:

class Field : IField
{
    public override bool IsValid { get; protected set; }
}

...will not be possible despite the fact that it meets the interface requirements conceptually.

IMO this has large negative implications for encapsulation that might be done via non-public Properties, and prevents a number of common use patters for Propertes.

I'm aware that you can create a non-public SetIsValid member that modifies a common backing store, but that would create an inconsistent pattern and add what would otherwise be code noise were it not necessary.

Have I missed something?

---

Edit: Yes I have missed something

I'm modifying someone else's code at the moment and just realize that the class I was wrestling with implemented the interface and derived from a base class. And I'm new to c# That's what caused the override confusion.

the actual class looked like:

class Field : IField, BaseField
{
    public override bool IsValid { get; protected set; }
}

...where BaseField implemented the interface as well, but did not implement the set.

Solution 1

This is perfectly legal. You don't need the override keyword (in fact it wouldn't compile) but there's nothing stopping you from doing this:

interface IField
{
    bool IsValid { get; }
}

class Field : IField
{
    public bool IsValid { get; protected set; }
}

Solution 2

It's possible on interfaces, but not on abstract/virtual properties - you may have these two mixed up.

Comments

[Catskul]

So if I were to pass an IField which refers to a Field object, and call IsValid, Field.IsValid will be called despite the lack of "override" ?

[Catskul]

Aren't all elements of an interface by definition virtual? (I'm somewhat new to c#)

[Gabe]

override applies to base classes that you inherit from, not interfaces that you implement.

[Catskul]

ah. I'm modifying someone else's code at the moment and just realize that the class I was wrestling with implemented the interface and derived from a base class. That's what caused the override confusion.

[Catskul]

I missed the real issue. See modified post. Thanks for the answer, it helped me see what I had missed.