Why is it illegal to have a private setter on an explicit getter-only interface implementation?

Question

I tend to favor explicit interface implementations over implicit ones, as I think programming against the interface as opposed to against an implementation, is generally preferable, plus when dealing with web-services it is often a necessity.

That said, I was wondering why the following is illegal with an explicit interface declaration and legal with an implicit one:

interface IConnection
{
    string ConnectionString { get; }
}

class Connection1 : IConnection
{
    // private set is illegal, won't compile
    string IConnection.ConnectionString { get; private set; }
}

class Connection2 : IConnection
{
    // private set is legal now, it is not part of the interface
    string ConnectionString { get; private set; }
}

I know how to fix this, as it is legal to have both an explicit and implicit interface, plus I can make the implicit interface implementation completely private.

Yet I am wondering about the reasoning behind this. Because technically, the internally compiled private method set_IConnection_ConnectionString does not need to be part of the interface, right? It could just be seen as an auxiliary setter, not part of the interface, as it is in the implicit implementation situation.

Update: as a bonus, the seemingly confusing, and in my opinion not quite right compile error you receive is the following:

The accessibility modifier of the accessor must be more restrictive than the property Connection1.ConnectionString

Excuse me, more restrictive than private, how... what?

Answer 1

The only way to invoke an explicit interface member is to cast the object to the correct interface and then invoke the member on that interface. But once you've cast to IConnection, the IConnection.ConnectionString has no setter.

So there's no way to invoke this private setter method.

Answer 2

The problem is that when an interface member is declared explicitly, the compiler generates a private implementation with an "unpronounceable" name, and provides no means by which code--even within the implementing class--to refer to that implementation.

Basically, when one says void IFoo.Moo(), one is saying that one does not wish to define a name Moo within the class scope; consequently, the compiler won't. In order for private set to work, the member would have to be a "pronounceable" name, and the fact that the member was explicitly implemented is taken as an indication that one does not want the name to be Moo.

In practice, the remedy here is probably the same as for many other cases where it's necessary to have an interface implementation whose name is pronounceable, but which is not exposed publicly under its name: declare an interface implementation which does nothing but chain to other members which have the proper accessibility, e.g. if derived classes should not be able to affect the value the value:

private readonly int _foo = whatever;
public int IFOO.Foo { get {return _foo;}}

or, if derived classes should be able to affect it, either

protected int _foo = whatever;
public int IFOO.Foo { get {return _foo;}}

or

private int _foo = whatever;
protected virtual int setFoo(int value) { _foo = value; }
protected virtual int getFoo() { return _foo; }
public int IFOO.Foo { get {return getFoo();}}

In vb.net, interfaces may be implemented using protected class members, but C# offers no such facility.