- "They've removed stuff in my Teams"
Today we looked an issue that has been requested by the community before, but now has new significance with source generators. In particular, the framework libraries are now starting to ship more functionality in source generators. These generators, such as the regex generator, are thought of as part of the API of the framework, but are defined as part of the user's library. This is concerning from a public API perspective, as internal implementation details of these generators are now much easier for users to access and take a dependency on. There's no existing scoping that can reliably separate generator-written code from user-written code, which then becomes an issue if (when) the framework will want to change internal implementation details of their generators. There is an additional problem that generators need to come up with deterministic-but-unique names, to ensure that they don't collide with other generators or with themselves, running from two different assemblies where assembly A gives B IVT.
In general, we agree with the first concern, and would like a mechanism to solve it. The latter concern, duplicated names within the same assembly, is where we spent most our time debating today. Having the compiler do name mangling is slightly concerning as it impacts the user experience in several ways: the IDE experience, the debugger experience, and the expression evaluator (EE) experience. These are all potentially solveable problems, but will take some design work to ensure it works correctly and seemlessly. After some debate, we feel that unless we were to allow duplicated names, this feature would feel incomplete. If a thing is file private, then allowing it to be visible in some other contexts feels like we didn't actually solve the problem.
We also thought about generalizing this feature. The proposal today specifically only applies to top-level types, and while they are the primary motivation currently, we don't think they should be the only one. More accessibilities has been a user request for a long time, applying to more things than just top-level types. Member fields or methods, for example, or nested types. It seems unfortunate to design specifically for just one small use case and not consider how it could be extended to other components in the future.
Finally, we talked a bit about the syntax. We're not sold on just using private here: private on nested types already means something, and just using private on the top level type would
be confusing. It would also interfere with extending a file private accessibility to other scopes. We could simply introduce file private as a new accessibility, or we could look at other
combinations like private internal.
We've settled our first big pivot point for this feature, that file private names should be able to be duplicated in multiple files in the same assembly. We will need to take the feedback from LDM today back to design and come back to a future LDM for the next elements.