Why must an implementing property in VB.NET have matching 'ReadOnly' specifiers?

Question

The following works in C#:

interface I
{
    int X { get; }
}

class C : I
{
    public int X
    {
        get { ... }
        set { ... }
    }
}

The following does not work in VB.NET:

Interface I
    ReadOnly Property X As Integer
End Interface

Class C
    Implements I

    Public Property X As Integer Implements I.X
        Get
            ...
        End Get
        Set(value As Integer)
            ...
        End Set
    End Property
End Class

The error message Implementing property must have matching 'ReadOnly' or 'WriteOnly' specifiers is pretty self-explanatory, so I do know what's wrong here. It's also not a big issue, because it's quite easy to work around this limitiation.

I'm curious, though: Does anyone know why the VB designers decided to treat this case differently than in C#?

Answer 1

I'm not sure about the VB side, but with the explicit interface implementation of I.X in C# you'd also get a complaint about the added setter:

interface I
{
    int X { get; }
}

class C : I
{
    int I.X  // explicit implementation of I.X
    {
        get { return 1; }
        set { }
    }
}

You get a similar error in C#. For the VB, may want to check out this SO thread: If an interface defines a ReadOnly Property, how can an implementer provide the Setter to this property?

Answer 2

You need to provide a read-only property to implement I.X; if you want YourClass.X to be a read-write property, then the read-only that implements I.X should be given another name (e.g.

    Public Property Xreadonly As Integer Implements I.X

I'm not quite sure why .Net requires the use of three types of properties (read-only, write-only, and read-write), rather than simply allowing an object which declares a read-only property and a write-only property to be used as though it has a read-write property, but it does. Perhaps its because they wanted to ensure that an override of a getter will follow the same inheritance path as an override of a setter, but it would seem there are cases where regarding getters and setters as separate items would be more useful (in some cases, for example, it may be useful to have a property Get method return a type which is distinct from, but coercible to, the Set method type; or it may be useful to have multiple overloads of Set; neither is allowed in .net, though).