search

dotnet / csharplang

The official repo for the design of the C# programming language
11.53k stars 1.03k forks source link

[Proposal]: file local types #5529

Open stephentoub opened 2 years ago

stephentoub commented 2 years ago

"file private" visibility

Design meetings

CyrusNajmabadi commented 2 years ago

@AraHaan that wouldn't solve a core case where you want the type hidden from code in the same assembly. A private class would be visible to siblings (just as a private nested type is visible to it's siblings).

jnm2 commented 2 years ago

@ViIvanov I like that, but it doesn't provide a solution for if you want only a nested type to be file-private.

ViIvanov commented 2 years ago

@jnm2, Thank you. Sorry, I've missed this case.

Pankraty commented 2 years ago

Will this make it possible to create private extension methods? I was in a situation a couple of times when something might be nicely expressed as an extension method, but that would be too specific for exposing as a method visible for the entire assembly. Top-level private class would solve that problem.

RikkiGibson commented 2 years ago

I would expect to be able to define extension methods in a 'file' class and only be able to use them in the same file. That's a great scenario to test, thanks.

BlinD-HuNTeR commented 2 years ago

I don't wanna be the party pooper, but, what's wrong with nested types? If you are writing a source generator, and you don't want the generated types to be visible to the main assembly, just make all the generated sources be part of a big partial class, and the generated types as nested private types in that class.

In other words, that big class is just acting as a namespace for all purposes. Even source compatibility is preserved, you're just transforming a namespace into a class that spans multiple files. The fully-qualified names of all the nested types will remain the same.

This should definitely be mentioned in the "Alternatives" section of the proposal, after all, it's a "Do Nothing" alternative.

CyrusNajmabadi commented 2 years ago

@BlinD-HuNTeR

"Do nothing" is always an implied alternative. When we decide we want to do something, it's because we feel that the value has already proven itself over "do nothing" :)

CyrusNajmabadi commented 2 years ago

In other words, that big class is just acting as a namespace for all purposes.

This came up as an option. We felt that this wasn't ideal and that defining something just for this purpose is unpleasant. We debated it but ended up here.

stephentoub commented 2 years ago

I don't wanna be the party pooper, but, what's wrong with nested types? If you are writing a source generator, and you don't want the generated types to be visible to the main assembly, just make all the generated sources be part of a big partial class, and the generated types as nested private types in that class.

There's no way to hide it completely. If the source generator is filling in a partial method on the user's type, that method needs access to the generated code; whatever it has access to, so will any other user code in the type containing that partial method. The only thing it can completely hide is anything it can generate inside the method itself, and without local types, there's no way to hide such types (and even if it had local types, there'd be no way to share that generated code across multiple partial method implementations without exposing it to the containing type's user code).

eerhardt commented 1 year ago

This was implemented in C# 11 right? https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/file.

Can this issue be closed?

stephentoub commented 1 year ago

@333fred, we keep these open until they're spec'd, yes? Or is that tracked elsewhere?

333fred commented 1 year ago

That's correct, but thank you for reminding me to label all the 11 issues appropriately.

Xyncgas commented 1 year ago

What if you are using a company git system and you are the one that can make change to your files and there is no easy way to clone your project because your git system is implemented in distributed performance with a blockchain backend therefore people are mad at you one day because you won't change your codes so that your methods are available to them which you are required by law to do so because it's the company's ip

AraHaan commented 1 year ago

@Xyncgas if that is the case, then you can safely skip using this feature without issues.

jrmoreno1 commented 1 year ago

@333fred: Could the check marks be added for prototype and implemented? I understand not closing until there is a documented spec, but I look for the check marks to know what stage it’s in

333fred commented 1 year ago

Done.

rob-ack commented 1 year ago

Consider 'file' not only being useful for type definitions. In the scenario of "code generation" or/and "partial types" the file keyword is "useful on any member". It would then allow to hide members which are needed for the generated or partial code to the other partial implementation details.

In my opinion file should be possible on any member as well (fields, properties, events, methods ...).

acaly commented 1 year ago

I found that issue that the IDE suggests me to convert some [DllImport] to [LibraryImport] on imported functions in a file scoped class. This is not possible because the generated implementation is in another source file, which has no access to the original definition.

RikkiGibson commented 1 year ago

In my opinion file should be possible on any member as well (fields, properties, events, methods ...).

Absolutely agree. We just need to come to a consensus for how file relates to accessibility outside of top-level types.

I would personally like us to be able to "just see file as another access modifier", but I don't think the LDM necessarily agrees with me there. What I mean is: file remains an exclusive "accessibility level" incompatible with other modifiers like internal/protected/private on a given member. There is a temptation to start defining things like file internal (another type in same file can use it) and file private (only the partial type declaration in the current file can use it), which starts to feel like a significant complexity burden.

When it comes to accessibility checks, file and private when the containing type is partial is kind of a Venn diagram. So when you want to start using file types in private signatures or vice-versa, the accessibility consistency errors could become painful.