Add public/internal/private visibility markers on inheritance, to stop contract propagation

[Daynvheur]

Hello,
Interfaces are part of the contract of an object, but sometimes that specific contract just don't have to be publicly exposed.

This example:

public abstract class MyAbstractExposedClass
{}
interface IDataYesExposedField
{ string? Yes { get; set; } }
interface IDataNoExposedField
{ string? No { get;set; } }
interface ILibraryApiFields
{
    string? Yes { get; set; }
    string? No { get;set; }
}
public class LibraryExportData : MyAbstractExposedClass, IDataYesExposedField, IDataNoExposedField, ILibraryApiFields
{
    public string? Yes { get; set; }
    public string? No { get; set; }
}

Api consumers may have no use for specific IDataYesExposedField and IDataNoExposedField contract detail. They may need it as part of the consumer's API, that is the (public) ILibraryApiFields contract.
Would it be possible to add public/internal/private visibility markers on inheritance, to stop contract propagation?

Something like that:

//...
public class LibraryExportData : internal MyAbstractExposedClass, private IDataYesExposedField, private IDataNoExposedField, ILibraryApiFields
{
    public string? Yes { get; set; }
    public string? No { get; set; }
}

Default contract visibility being implicitly public, to keep current level of service.

---

Defined goal

I need it when API objects are from a provider, then served to another customer, but I don't want to expose that level of contractness, without an object remap for privacy concerns.

Counterpoints

• Attributes + Roslyn Analyzer (from @KennethHoff)
  Workaround for class or interface inheritance tree, but won't apply to type checking
• Composition field (from @TahirAhmadov)
  Workaround for API exposure, but isn't an inheritence tree
• Access modifiers at the consumption level (from @tacosontitan)
  Private implementation are expected to not go down inheritence tree, it's an intended feature request
• Breaking the design philosophies that a derived type have that same contract as a minimum (from @HaloFour)
  This is valid point, but it would also be kept as the default (public) behaviour. Only explicit (non-public) visibility markers would have a change.

---

Please express your concerns below, counterpoints are welcome!

[KennethHoff]

I could see an attribute in conjunction with a Roslyn Analyzer can be used for this. Nowhere near as clean, but it can be done today :)

[InternalInterface<IDataYesExposedField>]
[InternalInterface<IDataNoExposedField>]
[InternalInheritance<MyAbstractExposedClass>]
public class LibraryExportData
{
    public string? Yes { get; set; }
    public string? No { get; set; }
}

[Richiban]

That doesn't help if you have an internal method with a parameter that's one of the interface types?

[HaloFour]

IIRC it was an intentional design decision that the contract of a subclass cannot be narrower than the contract of its base class. I don't believe the runtime even has a concept of narrowing implementation. You could use explicit implementation to at least hide the members, but the type will always implement the interface and could be cast to the interface to allow invoking those members.

[Daynvheur]

at the expense of breaking one of the original design philosophies of .NET, namely that if a base type has a contract then a derived type is guaranteed to have that same contract as a minimum.

The language permits that already:

public interface IParent
{ string? Parent { get; set; } }
public interface IChild // No IParent.Parent inheritance
{ string? Parent { get; set; } }
public class MyInterfacedClass : IChild
{
    public string? Parent { get; set; } // IChild.Parent implementation
    public void MyInterfacedMethod(IChild child) { this.Parent = child.Parent; } // Ok
    public void MyInterfacedMethod(IParent parent) { this.Parent = child.Parent; }; // Conversion from 'IParent' to 'IChild' emulated although not explicit
}

This unexplicit emulation is worse IMHO, since a change from IParent is not reflected onto IChild albeit expected, Code refactor is going to be hard, and current behaviour look like a code smell.

[HaloFour]

The language permits that already

That doesn't break the design philosophy at all. IChild doesn't implement IParent, so MyInterfacedClass doesn't implement IParent.

[Daynvheur]

I understand the philosophy point, and associated benefits.
In real use case though, IChild is expected to mirror IParent changes, without telling that publicly. The current code repetition isn't that much DRY.

[HaloFour]

You're not repeating yourself, you're being explicit about the contracts and their relationships.

[Daynvheur]

Being explicit about the contracts and their relationships is the expected public (implicit) behaviour.
Visibility marker language idea is intended to provide an alternative way to link objects within a defined scope, be it no limitation (as is the .NET philosophy current implementation), or narrower with specific meanings.

This is a philosophy breaking change for target application, not a language-wide groundening, by having some contracts explicitly not spreading around the entire provider-to-client code base.

[tacosontitan]

I'd expect access modifiers to be respected even at the consumption level which immediately makes private implementation useless:

public interface ISample { ... }
public class FooBar : private ISample { ... }
public void ProcessSample(ISample sample) { ... }
var foobar = new FooBar(...);

// Argument type 'FooBar' is not assignable to parameter type 'ISample'.
ProcessSample(foobar);

internal and protected are only marginally useful IMHO and the work to implement this would certainly outweigh the benefit those restrictions could even remotely provide.

You did make a point that I'm sure many can empathize with:

I need it when API objects are from a provider, then served to another customer, but I don't want to expose that level of contractness, without an object remap for privacy concerns.

However, in this case, I think if you want that level of control then mapping to another type is the best course of action to not violate consumer expectations. I agree with @HaloFour here in that I'd expect a derived type to contain everything from its parent at a minimum.

[Daynvheur]

I'd expect access modifiers to be respected even at the consumption level

I totally agree on this, and I answered to HaloFour with an example of this same pattern with a proposed CS1503:

public interface IParent
{ string? Parent { get; set; } }
public interface IChild : private IParent
{}
public class MyInterfacedClass : public IChild
{
    public string? Parent { get; set; } // IChild.parent
    public void MyInterfacedMethod(IChild child) { this.Parent = child.Parent; }
    public void MyInterfacedMethod(IParent parent) => MyInterfacedMethod((IChild)parent); // Should raise error CS1503: Argument 1: cannot convert from 'IParent' to 'IChild'
}

Thus making private modifier usefull aswell (in the exact intent of stopping contract propagation).

[Daynvheur]

Why the useless qualification to immediate private implementation, tho?

[tacosontitan]

@Daynvheur, if you have a class Sample that privately implements an interface IFoo, then on the surface, Sample should not look like it implements IFoo, and as such is not consumable as IFoo:

public interface IFoo
{
    int Bar { get; set; }
}

public class Sample : private IFoo
{
    private int Bar { get; set; }
}

...
IFoo foo = new Sample(); // invalid

In which case, why implement IFoo at all? You could just define Bar locally because you need it:

public class Sample
{
    private int Bar { get; set; }
}

Consequently, private implementation of an abstraction is useless.

[Daynvheur]

In which case, why implement IFoo at all? You could just define Bar locally because you need it:

The intent is to explicitly couple the interface contract within the class sole contractness:

internal interface IGatheredAPI //..From a distant endpoint
{
     string callresult { get; set; }
     string SetResult(string identity, string apitoken);
}
public interface IRebrandedAPI
{
    void SendCall(string id, string token);
    string callresult { get; }
}
public class RebrandedAPI : private IGatheredAPI, public IRebrandedAPI
{
    public string callresult { get; private set; }
    private string SetResult(string identity, string apitoken)
    {
        callresult = Encrypt(GatheredAPI.SetResult(identity, apitoken)); // Calls distant API endpoint
    }
    public void SendCall(string id, string token) => SetResult(id, token);
}

This is a way to make sure that any change in the IGatheredAPI contract is applied to the RebrandedAPI class, acting here as a strong hint syntax while keeping the consumer's inheritance tree unaware.

[TahirAhmadov]

internal class MyAbstractExposedClass
{}
internal interface IDataYesExposedField
{ string? Yes { get; set; } }
internal interface IDataNoExposedField
{ string? No { get;set; } }
public interface ILibraryApiFields
{
    string? Yes { get; set; }
    string? No { get;set; }
}
public class LibraryExportData : IDataYesExposedField, IDataNoExposedField, ILibraryApiFields
{
    MyAbstractExposedClass _compositionField;
    public string? Yes { get; set; }
    public string? No { get; set; }
}

[Daynvheur]

Using a (private) composition field is a clever workaround, but that doesn't solve the core concern that any change to the composited field will have to be manually carried around into business rule changes. Such decoupled behaviour may be expected, and should still work beside this discussion.

[Daynvheur]

As nobody stated, I can already do that with # directives:

//#define LIMITED_INTERFACES //Uncomment to activate limited-scope interfaces
System.Console.WriteLine(((IDataYesExposedField)new LibraryExportData()).Yes);

public abstract class MyAbstractExposedClass
{}
interface IDataYesExposedField
{ string? Yes { get; set; } }
interface IDataNoExposedField
{ string? No { get;set; } }
interface ILibraryApiFields
{
    string? Yes { get; set; }
    string? No { get;set; }
}
public class LibraryExportData :
#if LIMITED_INTERFACES
MyAbstractExposedClass, IDataYesExposedField, IDataNoExposedField,
#endif
ILibraryApiFields
{
    public string? Yes { get; set; }
    public string? No { get; set; }
}

Thanks for your attention.