[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.

[jaredpar]

got your response on mail, but don't see it there.

Cause I decided I wanted to rethink one part of it so I deleted the message.

[jaredpar]

Well, that's exactly what I want to get from you. I want to get a list of problems for this proposal so I can find a resolve for them.

A significant part of feature design is discovering the problems. It's a task that often takes a significant time commitment. This isn't a case where I know the problems and are refusing to divulge them, instead it's a case of it's a tricky area and no one has sat down and paged it all in to think through what the problems are. Part of proposing a feature is doing that work.

Consider as an example the proposal I filed recently for allowing yield in a try / catch. That is a relatively simple change, just remove a restriction around yield. But it took me 3-4 hours of digging into the topic, chatting with people involved in related features or the original design to fully understand the set of problems that I needed to solve. Anything with interfaces and visibility is going to be significantly more complex than that.

So your observability protection doesn't work at the moment.

Correct. This is one of the reasons I deleted my answer last night. I thought through a couple of cases where I could expose the type today that were similar. The guidance to file authors is if you have that in a impls / base list then there is some amount of external exposure that you're taking on.

The explicit interface proposal does up the exposure to a new level because it allows you to get instances of the types via a type parameter. For example:

// file1.cs
M(new C1());
void M<T>(I1<T> p)
{
    // T is a file type now
    T local = p.Prop;
}

// file2.cs
class C1 : I1<C2>
{
    C2 I1<C2>.Prop => new C2();
}
interface I1<T>
{
    T Prop { get; }
}
file class C2 { }

Essentially now I can get T instances which are file types in another file. That's an escalation of capabilities, not sure how severe it is / isn't.

Other areas I would want to dig down into is:

• How does this impact binary compat? Every change you make to the file will change the type identity of a file type within it. Now that these can be exposed through interfaces are we creating any subtle binary compat issues. Basically is there a way for code outside this assembly to now depend on file type since it was exposed via an interface? If so that would be pretty fragile.
• Can I use partial to get to the file type? Essentially if the class implementing the interface is split between files via partial can I use that to get access to the file type outside the file? Basically split the interface implementation up amongst the partial declarations. I think that is okay because explicit implementation requires the type argument to be stated but would want to dig into all those rules.

thus implementing a new accessibility modifier case of file with standard CS0122 should be an option. I wonder why you think that we should leave exactly one way to handle file-visibility when we can support both of them

If you want to push the issue of file being an accessibility modifier I think you should file a separate proposal that is specifically aimed at it. As I've mentioned a few times, C# LDM (not me specifically) considered and rejected this idea. Suggest looking through the design meetings, internalizing the rationale and providing reasons why you think the decision was incorrect.

[ShadedBlink]

This isn't a case where I know the problems and are refusing to divulge them

I am sorry if you had a feeling that I sense any offense from you or etc. I am just curious about implementation as well too and want to dive deeper in subject because I don't know everything as well. Thus I am probing in problems and proposal variations.

The explicit interface proposal does up the exposure to a new level because it allows you to get instances of the types via a type parameter.

Actually I don't think that given case is the problem as for now we are free to store file-scoped types in object fields of a public class. Even more, if file-scoped type implements any interface or base type, we are free to publicly store it as given type. It was my previous implementation before refactoring, so I guarantee that following implementation is working.

class C1
{
    public I1 Field = new C2();
}
interface I1
{
}
file class C2 : I1 { }

Thus we get in the situation when we are free to display our file-scoped objects publicly in any way except when it is used as generic argument of interface. No offense, but that sounds totally stupid.

How does this impact binary compat? Every change you make to the file will change the type identity of a file type within it. Now that these can be exposed through interfaces are we creating any subtle binary compat issues. Basically is there a way for code outside this assembly to now depend on file type since it was exposed via an interface? If so that would be pretty fragile.

As we already know, we have no way to make direct dependency on file-scoped type due to lack of type discoverability. Thus recompilation of library with new name of such type definitely won't break anything. So we have only indirect internal dependency left, i.e. user code should depend on the fact that object's type implements any interface or has some other property like "Type.Name starts with FileLocalType". This is absolutely same as dependency on internal implementation, so responsibility is on the user code. If we allow users to get instances of file-scoped types(as in previous example), I see no problem with them getting instances of those types by generic arguments.

Can I use partial to get to the file type? Essentially if the class implementing the interface is split between files via partial can I use that to get access to the file type outside the file? Basically split the interface implementation up amongst the partial declarations. I think that is okay because explicit implementation requires the type argument to be stated but would want to dig into all those rules.

partial definitely should not allow us to get file-scoped types. file limits to file, not to type like private. More so, this modifier should be especially usefull when you split complex type in different files. Thus we can leave some logic exclusive to one part of the class, other part is exclusive to other part. If we extend file to partial, then such split is impossible.

If you want to push the issue of file being an accessibility modifier I think you should file a separate proposal that is specifically aimed at it. As I've mentioned a few times, C# LDM (not me specifically) considered and rejected this idea. Suggest looking through the design meetings, internalizing the rationale and providing reasons why you think the decision was incorrect.

It would really be much easier to just create another proposal, but current implementation of privacy of file just can't leave me be. It doesn't hide file-scoped objects at all, only the type, i.e. it works exactly like an accessibility modifier. The only difference is that we can't create file-scoped interfaces. Just try to look at other difference for this case from public-private relation - you won't see any. This protection you told about is implemented so bad that I even had no idea that it was a target.

• You can't create public members with private types - same for file.
• You can create public members with private objects by their parent or interface type - same for file.
• You can't inherit private base type with public descendant type - same for file.
• You can't inherit public base generic type with private generic argument - same for file.
• You can implement private interface in public type - same for file.
• You can implement public generic interface with private type - same for file.
• You can implement public generic interface with private generic argument - same for file.
• You can't explicitly implement members of public generic interface with private generic argument in declarations - same for file.
• You can implicitly implement members of public generic interface with private generic argument in declarations - same is not possible for file.

[ShadedBlink]

@jaredpar , any thoughts on this one for all this time? As of C#13, the only difference in behaviour between file and normal accessibility modifier is still only in generic interface implementation, everything else is similar.

[CyrusNajmabadi]

It's basically asking for a lot of work (especially investigation wise) for marginal gain. Could you consider not using a file-type in this case?