Allow nested file-local types

[mgravell]

Summary

Currently, the file scoped modifier is limited to top-level types; attempting to use the modifier in a nested type gives CS9054

File-local type 'X' must be defined in a top level type; 'X' is a nested type.

I am ignorant of the reasons for this, but: it creates some problematic scenarios around accessibility.

Consider:

Motivation

// user code
partial class Foo
{
    partial interface IBar // note non-public
    {
        void Blap();
    }
    // other user code here that uses IBar
}

where we want a generator to do something like:

// generated code
partial class Foo
{
    [Proxy(typeof(GeneratedProxy_IBar))] // some library-specific marker attribute
    partial interface IBar { }

    // this type does not need to be available anywhere other than the attribute
    class GeneratedProxy_IBar : global::Foo.IBar
    {
        // TODO: do something interesting
        void global::Foo.IBar.Blap() => throw new NotImplementedException();
    }
}

We do not intend for GeneratedProxy_IBar to be visible or accessible to regular code - it is used only via the attribute at runtime, to skip a ref-emit layer (think: AOT). It would be an ideal candidate for file, however:

• if we add file where it is currently, we get CS9054 (file-local must be top level)
• if we add file and move the type to top-level, we get CS0122 (accessibility)

Our only option currently is to leave the type unnecessarily visible to user code. Not insurmountable, but ugly and vexing, especially as it is only the reduced accessibility of IFoo that has blocked us from masking the generated type.

Workarounds

We can also add a bunch of attributes [Browsable(false)], [EditorBrowsable(EditorBrowsableState.Never)], [GeneratedCode("...","...")], [DebuggerNonUserCode] on the generated type, which may help a little, but isn't quite the same as an unspeakable name.

Suggestion

Remove the limitation on the file modifier to top-level types, since there are scenarios where they may usefully apply to nested types.

Thoughts?

[bernd5]

You could make the nested type GeneratedProxy_IBar private.
file wouldn't help - that type would be only accessable from the file where it is defined - and the generated code is not in the same file...

[mgravell]

1. it will already be private by virtue of C# defaulting to least-accessible; however, it is still unnecessarily visible/accessible to all of the // other user code here that uses IBar
2. file absolutely would be useful here: it is visible to our [Proxy(typeof(...))] in the same file (// generated code), which is literally the only place it needs to be referenced; the compiler embeds the unspeakable name into the metadata, and code that discovers this via reflection: is perfectly happy with such types (they just have weird names); the exact same trick using top-level file types for the proxy when this combination of nested plus inaccessible doesn't apply: works great

[bernd5]

You are right - members of non interfaces are by default private.
I thought you would need to access the generated type from non generated code...

The problem is now that this nested type needs to access restricted (e.g. private) member. In this case I agree file would be nice.

But what is the difference to:

• roslyn renames the type to something like: <_>FD2E2ADF7177B7A8AFDDBC12D1634CF23EA1A71020F6A1308070A16400FB68FDE__GeneratedProxy_IBar
• your generator creates such an ugly name (without '<' and '>'?

Where is a private type visible where you don't want it to be?

[mgravell]

Where is a private type visible where you don't want it to be?

all of the // other user code here that uses IBar - i.e. any user code inside Foo can see the generated type.

But what is the difference to:

One is visible and touchable by regular code, one is not; the same question/logic could be applied to all file scoped types, so: the fact that file exists at all strongly suggests that it is sufficiently desirable to be able to restrict visibility like this.

[bernd5]

I see, code completion...
You could use a random name - but it is ugly. I agree.

[mgravell]

I guess the implementation problems here are around "is it the same named-type-symbol when used in different places, or are there now two different and competing named-type-symbol definitions for the same type? what type members does the named-type-symbol advertise in each scenario? what are their advertised names and other metadata?"

I don't know enough about Roslyn to opine on whether those are problems that need addressing (or indeed, whether I'm wrong and this isn't the concern at all)

[bernd5]

From my perspective there should be no real problem in roslyn. Not sure why the modifier was limited to top level types only.
AFAIK the original proposal wanted file to be a general access specifier - not only for types (e.g. functions etc.).

[mgravell]

Hmmm; in this specific case, a valid workaround (from C# 8 onwards, so: precedes file) is to move the proxy inside the interface (as private):

// generated code
partial class Foo
{
    [Proxy(typeof(GeneratedProxy_IBar))]
    public partial interface IBar
    {
        // this type does not need to be available anywhere other than the attribute
        private sealed class GeneratedProxy_IBar : global::Foo.IBar
        {
            // TODO: do something interesting
            void global::Foo.IBar.Blap() => throw new NotImplementedException();
        }
    }
}

which is an improvement (it is still visible / accessible inside IFoo) - the general concept still feels like an open question, though.

[RikkiGibson]

This is something I want to do eventually, as well as file for non-type members. We were stuck on this because we couldn't agree on how the accessibility should work, e.g.:

class C
{
    file class Inner { }
}
class D : C.Inner { } // is this allowed?

[mgravell]

Gotcha. Not that you asked, but to me, the answer would be "yes", but there's some real gnarly accessibility issues if Inner uses (on it's public/internal API) anything that isn't fully public/internal - for example, if it uses the private type C.Evil in a constructor. Yeah, some fun problems.

[ds5678]

This is something I want to do eventually, as well as file for non-type members. We were stuck on this because we couldn't agree on how the accessibility should work, e.g.:

class C
{
    file class Inner { }
}
class D : C.Inner { } // is this allowed?

While I'm sure this was mentioned by a team member, my opinion is that:

• file is (should be) a modifier that does nothing except limit access to the current source file.
• A type/member with the file accessibility modifier has the same accessibility within the file as it would if it had no accessibility modifiers at all.
  • Top level types are internal.
  • Members and nested types are private.
• If a user desires to deviate from default accessibility, they can specify that accessibility after the file modifier, eg file internal.
  • file must always be the first keyword.

In your example, D would not be able to inherit from C.Inner unless that class is changed to have file internal accessibility.