[Proposal] File-scoped types in explicit interface implementations. #8357
Replies: 2 comments 16 replies
-
|
How is this different from other non-public access levels, like 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 {
} |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
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 // 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. |
Beta Was this translation helpful? Give feedback.
-
|
@jaredpar , got your response on mail, but don't see it there.
I am okay with having such For your example, there is a compilable code. It works right now and there is no restriction for it in // File1.cs
void M<T>(IIsRelatedTo<T> i1) {
Console.WriteLine($"{i1.GetType()} is related to type {typeof(T)}");
}
// File2.cs
public class C1 : IIsRelatedTo<C2> {
void IIsRelatedTo<C2>.DoSomething() => throw null!; // no error!
}
public interface IIsRelatedTo<T> {
void DoSomething();
}
file class C2 { }
I understand that file-involved discoverability is not an easy thing to do, thus implementing a new accessibility modifier case of |
Beta Was this translation helpful? Give feedback.
-
|
By the way, I suddenly found a way to overcome this problem. It is compilable, it is working, but it is awfull. |
Beta Was this translation helpful? Give feedback.
-
Cause I decided I wanted to rethink one part of it so I deleted the message. |
Beta Was this translation helpful? Give feedback.
-
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
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 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 Other areas I would want to dig down into is:
If you want to push the issue of |
Beta Was this translation helpful? Give feedback.
-
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.
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.
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 "
It would really be much easier to just create another proposal, but current implementation of privacy of
|
Beta Was this translation helpful? Give feedback.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions