All types should be partial by default

[YairHalberstadt]

Most source generators work by adding members to user declared partial types. This means that the user needs to declare the type with the partial modifier. This adds a lot of noise to code bases which make heavy use of code generators.

I very much hope that code generators will become much more commonplace post c# 9.0. For example I expect it will be common for code bases where performance and security are low prioirities but debuggability is paramount to use source generators to automatically implement ToString/DebuggerDisplay on all types. Other code bases may use source generators to override the default record behaviour for example.

However with the need to explicitly declare every single type partial I can't see this happening.

I propose that all types become partial by default to allow source generator usage to be more implicit and less noisy.

Objection 1: what if I accidentally declare two types with the same name.

A simple solution would be to only allow at most one declaration of a type to omit the partial modifier. All others must explicitly declare the type as partial. This will allow users to omit partial whilst source generators will have to add it.

Objection 2: I like the explicitness of the partial keyword.

This is a valid point, but I have a number of counterpoints:

1. let's see how you feel about this in five years :) http://gafter.blogspot.com/2017/06/making-new-language-features-stand-out.html?m=1
2. The partial keyword doesn't do a great job at this anyway. It's used for a number of other purposes, not just to tell you that some code has been generated. If the language team feels like source generators need some special syntax, then they should add that, not use partial as something that happens to sorta work.
3. There's two sorts of code generators. Those that are triggered by something explicit in the user code (an attribute, an interface etc). For these partial is superfluous. And those which should apply to every type. For these partial is unwanted and way too noisy.

[333fred]

I'm somewhat interested in this idea, though I will also want to see what the initial reaction to source generators is as well. I certainly wouldn't want all types to be automatically partial. I'm more amenable to the "all types can can have at most one file not marked partial". My ideal here would be "if there are multiple user-defined files for a single type, that type must be marked partial in every definition." However, that would require us to define what a generated file vs a user-defined file is.

[canton7]

I like the certainty of knowing that a non-partial type is not going to be modified by a source generator: I like having a marker that sticks out saying "this class is more than it seems: go looking if you want to see what else it can do". Even if you don't happen to know that a particular attribute triggers a source generator, partial tells you unambiguously that there's more going on somewhere else.

Source generators are effectively hidden magic. That can be a good thing, but it's nice to know clearly where magic is happening and where it definitely isn't.

[jnm2]

I wasn't sure I liked this idea, but my next thought was http://gafter.blogspot.com/2017/06/making-new-language-features-stand-out.html. And partial is not useful for the purpose of reminding me that a source generator may add members because I use it so much already.

[canton7]

Yeah it doesn't warn you specifically about source generators, but it says that something exists somewhere else, and you can ask VS to take you there. One of those places might be a source generated file, or it might not. But it's an indicator to go and look.

I appreciate gafter's point, but your proposal lets source generators change things without any indication whatsoever. I don't think an indication needs to stand out necessarily, but I think there should be something.

[TheUnlocked]

In theory the editor should be able to indicate to the programmer that a class is affected by a source generator, right? I feel like that's better than requiring people to sprinkle partial around everywhere.

[YairHalberstadt]

I appreciate gafter's point, but your proposal lets source generators change things without any indication whatsoever.

Once source generators are more common, then it will just be default knowledge that source generators can add members to objects. You wont need a visual cue that that can happen, because it will be as obvious you as the fact that other files can declare other types, even if they're not declared in this file.

I think the requirement to use partial explicitly will prevent source generators ever reaching that level of ubiquity. So essentially this is a decision about how the csharp team wants source generators to be used: loudly in targeted specific cases, or ubiquitously and implicitly wherever they could come in useful.

[DavidArno]

I have the complete opposite view to partial the OP. I too anticipate that source generators will take off. But I absolutely disagree that needing to put partial everywhere would be an impediment to this. That keyword is a handy marker of the fact that there's more to the class than is there in front of me. There's generated functionality too. The same will apply with source generators: they are creating extra functionality and I want that made clear via that partial keyword.

[YairHalberstadt]

To reduce this to a single question:

Should source generators be able to be used to add DebuggerDisplay to every single type in my project?

If yes, then the only way to enable this practically is to remove the need for the partial keyword. Otherwise every single type will have to be declared partial, which is extremely noisy, ruins the git blame, and at which point the partial keyword tell me nothing useful.

If no, then requiring the partial keyword is a reasonable way to prevent this happening.

[PathogenDavid]

I'm also concerned about the viability of source generators that are intended to affect large amounts of the codebase.

In my opinion, instead of potentially damaging the value of partial in the context of human-written code, there should be an forced-partial (IE: inject) that can (only?) be used in code from a source generator.

I don't think partial is a good indicator of "This type is affected by source generators." I agree with @TheUnlocked that that problem is better solved by tooling.

[DavidArno]

@YairHalberstadt,

That's a neat single question that shows our differences. To me, the answer is "absolutely not". The idea of a source generator changing every type in my project is abhorrent to me. But clearly you see it as a positive.

[PathogenDavid]

though I will also want to see what the initial reaction to source generators is as well.

While it wasn't merged, judging by Unity-Technologies/roslyn#17 it appears that this has caused the Unity developers some headaches.

[canton7]

Once source generators are more common, then it will just be default knowledge that source generators can add members to objects.

Right, but I'd rather not have to individually use "Go To Definition" on every single type to figure out whether the source generator has added any members. I would certainly not expect a source generator to be modifying every single type in my assembly.

Adding DebuggerDisplay to everything seems pointless: if there's an algorithmic way of generating a suitable DebuggerDisplay attribute, then why not put that logic in the debugger? A different issue applies to adding ToString to all types: this will have a nasty habit of leaking secrets into log files. Having done automated ToString methods using S.L.E, you absolutely need to be opting into it on every type in order for it to be safe.

And if you do want to be able to modify every type in an assembly, then change your VS template to add partial to every class definition. That way anyone coming onto the project knows what's going on.

People just don't like impenetrable magic. They don't like things happening that are hard to discover. It's one of the reasons so many people hate things like ioc containers.

---

I do like the idea of the IDE showing an indication that a type has source-generated members. Possibly even going so far as to show the signatures of these generated members in the user's source file. But I do think that only allowing source generators to touch types which have been explicitly whitelisted by the user can only be a good thing. It also gives users an easy way of stopping a source generator from modifying a type if it's misbehaving in some case.

[YairHalberstadt]

It also gives users an easy way of stopping a source generator from modifying a type if it's misbehaving in some case.

This will probably not work well. My generator for example will always generate the type, and then expects the user to fix the error if it's not partial. Even those that do special case this will probably produce a diagnostic to warn that it's missing a partial.

Source generators who are going to the effort to support this should instead just support an explicit suppression attribute. That will work much better, and allow blocking one source generator and not another.

[CyrusNajmabadi]

In theory the editor should be able to indicate to the programmer that a class is affected by a source generator, right? I feel like that's better than requiring people to sprinkle partial around everywhere.

It's not about any sort of indication. It's about me not wanting generators to be able to touch my types unless i give them explicit permission with 'partial'.

[canton7]

This will probably not work well. My generator for example will always generate the type, and then expects the user to fix the error if it's not partial. Even those that do special case this will probably produce a diagnostic to warn that it's missing a partial.

You might want to fix that 🙂 Diagnostics are suppressible, that's OK.

[theunrepentantgeek]

@IllidanS4 that would take the language down the path of multiple dialects of C#, something the LDM has been extremely clear about avoiding.

[IS4Code]

@theunrepentantgeek Will it really? You have using, checked, unsafe, all of which affect the behaviour of code that could be lines below it. If you talk in English and suddenly change the subject or the context of your speech, you don't create a dialect of English.

Tell me, what does this class do?

class C
{
}

If you answered surely nothing, you would not be correct. It derives from List<object>, has a single constructor with an IntPtr parameter, and it also implements IDisposable and has a finalizer. And yeah it is also actually thus visible to anyone outside the assembly. Why, you ask? Well there is public partial class C : List<object>, IDisposable somewhere, you know?

Pragmatically, this cannot work without any sort of explicit configuration, or things will take a very confusing path very quickly.

[PathogenDavid]

@IllidanS4

If you answered surely nothing, you would not be correct.

I'd certainly be correct with valid C# code today because if there was public partial class C : List<object>, IDisposable somewhere, I'd get error CS0260: "Missing partial modifier on declaration of type 'C'; another partial declaration of this type exists"

Introducing a per-project/per-file toggle makes it ambiguous, which was @theunrepentantgeek's point.

[IS4Code]

@PathogenDavid I was speaking in the context of this propsal of course. Introducing a toggle does make it ambiguous, but having the current behaviour as the default one will force everyone to either state it is toggled or assume it is not otherwise.

[jnm2]

@IllidanS4 Yes it will, really. "Dialect" is the term the language design team uses. They regret the /unsafe and /checked switches and they added the /nullable switch only because the value of NRTs was so huge and there was no good way around it.

[MgSam]

Is DebuggerDisplayAttribute really even all that useful anymore? Since Visual Studio added pinnable properties while debugging, ToString and DebuggerDisplay have become far less useful to me.

[jnm2]

@MgSam Yes. It saves first-time discovery about what properties are interesting and it saves scrolling, waiting, and clicking. All things which are lost if you git clean.

[canton7]

The "interesting" properties are type-specific, surely?

[KalleOlaviNiemitalo]

This would make it more difficult to verify that Platform Invoke struct types have the same fields as in the unmanaged API.
Perhaps that could be mitigated with a new analyzer and AllInstanceFieldsInSamePartAttribute.

[gulshan]

#950 has some prior discussion. I closed it eventually.

[marsej]

Could a project property that tells the compiler that every class under specified namespaces get "partial" do this?
eg.
Step 1 Go to project properties
Step 2 Select whatever tab this would go under
Step 3 Enter namespace
Every class under specified namespace gets "partial"
optional: Step 4 Have IDE show in the code the "partial" somehow in special color to remind this is in effect.

[TahirAhmadov]

What about adding another keyword to the second and subsequent partial type definitions which would allow one (the first or "main" one) to skip the partial keyword?

class Foo
{
}
// elsewhere - say, generated code
explicit partial class Foo
{
}
// no errors when "explicit" is added

[CyrusNajmabadi]

Allowing something else to opt my own types into being partial seems go against one of the major design reasons behind partial in the first place. Namely that the type author be in control here and that the type be apparent at its declaration that it was partial.

[TahirAhmadov]

Sure, but that reasoning really precludes any omitting of partial keyword.
My idea was to make it safer - no accidental "opting in" - the user has to "force" it.

[franchyd]

Is using partial for both source generators and multi-file user definitions the problem? Could generated files be specially handled to not require "partial" in user-written code? I.e. a generated keyword that in the generated code that works the same as partial but doesn't require the keyword in the user-written code?

This would allow the unhindered pathway to ubiquitousness for source generators while still preventing user born issues with an implicit partial.

As for @CyrusNajmabadi's argument regarding opt-in for Source Generators on types. That would be better handled in the source generators rather than at the language level. If a source generator is touching types/methods/properties you don't want, either enhance the source generator to add better granularity of control or stop using it.

[CyrusNajmabadi]

Could generated files be specially handled to not require "partial" in user-written code?

A couple of things:

1. this breaks the invariant we have today where a generated file is not special, and that you can just take a generated file, emit it to real file, and end up with the same results. So that would be a tough change to make.
2. i actively do not like this. That the code is generated doesn't change that i want my own code to be explicit that it is partial and thus it is ok for a generator to add to it.

I see no problem with the state today where one of my types might not be partial, but the generator can have an analyzer that emits a diagnostic saying it needs to be.

[franchyd]

A couple of things:

1. this breaks the invariant we have today where a generated file is not special, and that you can just take a generated file, emit it to real file, and end up with the same results. So that would be a tough change to make.
2. i actively do not like this. That the code is generated doesn't change that i want my own code to be explicit that it is partial and thus it is ok for a generator to add to it.

I see no problem with the state today where one of my types might not be partial, but the generator can have an analyzer that emits a diagnostic saying it needs to be.

The first point is inarguably a valid one, that would be a pretty tough change.

For the second point though, generally source generators are controlled by Attributes. The attributes are the explicit opt-in aren't they? Why have two systems for doing the same thing.

[CyrusNajmabadi]

The attributes are the explicit opt-in aren't they? Why have two systems for doing the same thing.

The point is: if i don't have the attribute on me, the generator can still augment my types without me saying that's ok.

[theunrepentantgeek]

The attributes are the explicit opt-in aren't they?

They're opt-in to have a source generator pick up something as a basis for generation.

That generation doesn't necessarily have to be a partial that gets merged into the original. It could be other things - subclasses, utility classes, extension methods, the list goes on.