[Proposal] File-scoped types in explicit interface implementations.

[ShadedBlink]

Allow file-scoped types in explicit interface implementations. Those members are inaccessible without explicit conversion to given interface, thus it is safe to allow them use file-scoped types in their declarations.

public class PublicType
    // This is already supported since C# 11.
    : IList<FileScopedType> // Totally okay, we can declare interfaces with file-scoped type since no one can cast our `PublicType` instance to `IList<FileScopedType>` outside of this file.
{
    // This is still restricted in C# 12.
    void IList<FileScopedType>.Add(FileScopedType arg) // Totally okay, since no one can access this member without casting this type to `IList<FileScopedType>`, what is obviously possible only in current file.
    {
        throw null;
    }
}

file class FileScopedType {
}

[TahirAhmadov]

How is this different from other non-public access levels, like internal?
Either way, it should be like this:

public class PublicType
    // This is already supported since C# 11.
    : explicit IList<FileScopedType> // has to have "explicit" keyword (don't know if it should be before or after)
{
    void IList<FileScopedType>.Add(FileScopedType arg)
    {
        throw null;
    }
    public void Add(FileScopedType arg) { } // compilation error: inconsistent accessibility, and 
    // if explicit method above is absent, also "method Add not implemented"
}

file class FileScopedType {
}

[ShadedBlink]

It is different in the way how it is treated in current assembly. Sometimes you want to isolate some logic inside the assembly and don't want to extract it to a new assembly. Thus you can isolate such logic in given file, and it won't interfere with intellisense and code in other classes. For example, you have multiple classes that use some individual helper classes/structures with similar names, but they share no domain logic. Of course, we can just declare them internal and isolate in own namespace, but they will appear in intellisense suggestions anyway. Also we can make them private, but what is the point of file-scoped types then?
My main idea is that we already have private/internal interface implementations. We can use them only in current assembly or in current class. I want to extend file-scoped logic to allow interface usage only in current file(I.e. more than a class visibility, but less than an assembly visibility).

[jaredpar]

Totally okay, since no one can access this member without casting this type to IList<FileScopedType>, what is obviously possible only in current file.

That is not correct. It can be accessed with generics. Consider the following:

M(new PublicType());
void M<T>(IList<T> list) { 
  list.Add(null);
}

In this case T would be FileScopedType. That by itself isn't really violating the principal of file scoped types because you can't really do anything with T. But it's easy to extend the samples a bit where you can start probing into the file scoped type. Consider the following:

// file1 
class Col: IEnumerable<FileType> {
    public IEnumerator<FileType> GetEnumerator() => throw null;
    IEnumerator IEnumerable.GetEnumerator() => throw null;
}

class FileType : IDisposable 
{
    public void Dispose() => throw null;
}

// file2 
var col = new Col();
M(col);
void M<T>(IEnumerable<T> e) where T : IDisposable
{
  foreach (var t in e) {
    t.Dispose(); // Calling File scoped type member from diff file
  }
}

The ability to observe the shape of a file scoped type like this goes very much against their design.

[ShadedBlink]

What I mean is that I see that given generic interface implementation restriction is wrong and it should be lifted. I just want to either get this vision accepted as an issue or get some explanation for why it should be left as is. I am okay if it is not implemented for a long time due to implementation complexity since dotnet devs will be atleast aware of this bug. At the moment I still have not got any valid explanation for refusal.

[CyrusNajmabadi]

At the moment I still have not got any valid explanation for refusal.

Jared's reasons seem valid to me. Regardless, if a team member wants to champion this, they can do so.

[jaredpar]

I already provided here analysis on differences between file and private, which heavily contradict with @jaredpar explanation that file has a different purpose from a normal accessibility modifier, and is meant to keep objects(not types) isolated from outer world.

To be clear: it is the explicit view of LDM that this is not an access modifier. There is overlap in functionality but it is meant to serve a different purpose than traditional access modifiers. This is not a case of my pushing my opinion on the behavior here (I was actually for having it be an accessibility modifier but we decided the other direction).

I am okay if there will be atleast an issue created noting this proposal, even if nobody will take it in for development for a long time

Issues are only created now when there is an LDM member willing to sponsor the proposal. It is not created just to note an idea, that is what discussions are for now.

At the moment I still have not got any valid explanation for refusal.

There are some issues for which there is an explicit "no we can't do this because X". This issue falls more into the category of "probably works" but also needs deeper vetting and has to cross the "is it worth the -100 points all proposals start with bar". It's not that we're refusing to do this, it's just that none of the LDM members are thus far inspired to champion this.

[ShadedBlink]

Issues are only created now when there is an LDM member willing to sponsor the proposal. It is not created just to note an idea, that is what discussions are for now.

Well, that's enough for me. Then I will just hope that sometime later this will be finally fixed.

[martin-steinhoefer]

The issue though is CS0122 is observable

Okay, lets use CS0311 then. Nobody can see this interface outside, ...

That is obviously not true. The list of implemented interfaces is part of the declaration of PublicType and as such is public knowledge as the type itself is public. That can be proven like this

var isEnumerable = (new PublicType() is IEnumerable); // will return true

although IEnumerable is not IEnumerable<T>, that line shows, that any interface implemented by a public type is visible, even if one can't write the name of that interface down in C# (you can't write down IEnumerable<PublicType.PrivateType>, b/o PrivateType is inaccessible). However, via reflection one is able to get the inferred type object of the generic type argument for further use.