Feature request: Partial enums

[TheProxyRE]

Ok so I thought of maybe of doing the partial keyword on enums
for large enum files like for example cil OpCode list

Example

for example to do it like this

//ArithmeticOpCodes.cs
public partial enum Code
{
Add,
Div,
Mul,
Rem,
Neg
}

and

//ArithmeticBitwiseOpCodes.cs
public partial enum Code
{
Shl,
Shr,
Shr_Un,
And,
Or,
Xor,
Not
}

and after compiling those 2 (or more) concatenate like any other normal enum in finalized clr module

Issue

The only issue I can see here is the order of unspecified enum values
in the case above its not sure which enum part should be "First" in ordering
so I thought maybe to sort it by file name, or if user want to change the order
maybe some enum placeholder can be done like

//ArithmeticOpCodes.cs
[RosyinEnumUtilis(Order = 0)]
public partial enum Code

//ArithmeticBitwiseOpCodes.cs
[RosyinEnumUtilis(Order = 1)]
public partial enum Code

or by simply specifying the first value in enum like in standard c language
like

//ArithmeticBitwiseOpCodes.cs
public partial enum Code
{
Shl = 10,
Shr,  //should be 11
....
}

[brabebhin]

[itaibh]

of course it can. we generate enums from some source-of-truth, but need to keep "removed" enums as deprecated for backward compatability.

[TheProxyRE]

But why? Partial classes make sense when using designers and other code generation tools because they separate human authored code from machine generated code. This cannot be done with enums.

Why wouldn't it be enum is just a class when compiled and partial on enum would yield the same result.
Enum, when compiled, is class with System.Enum as a class and const int fields that represent their values.
And this wouldn't affect anything compiler wise either because of compiler doesn't use those fields most of the times, it 90% because it instead of using ldsfld opcode with Const field, it just use const value and load as plain integer, fields are used only when you want to do something thru reflection with them, or enumerate all enums, but still partial wouldn't mind this because it concatenates all partials into 1 large class. Also this concatenation works for all partial classes, wouldn't be just for enums, I can recommend you to compile a couple of partial classes into some assembly and check the result with some IL viewer (i recommend dnspy you can find it here on GitHub)

Also if you work with large enums it's much easier to sort/separate them in partial classes so it's easier to navigate thru them

[Tom01098]

You can always format your enum using whitespace and comments.

It seems like this would be a lot of work for the language team for something that doesn't provide that much benefit. As stated already, partial classes were made to make using code generation tools easier. You wouldn't want a generator to create your enum values, or at least I can't think of a scenario for it.

[HaloFour]

Why wouldn't it be enum is just a class when compiled and partial on enum would yield the same result.

As you mentioned, the difference with enum is that the order of the members matters. To implement this feature the compiler team would have to add new features that would explicitly specify that behavior. Given said behavior would have no utility outside of partial enums that would mean that partial enums would need to provide enough of a benefit to justify that cost in terms of time and effort. I believe that the number of enums that would benefit from this feature, either due to being excessively large or due to being partially generated, is vanishingly small.

[DaZombieKiller]

That gets me wondering: what happens with [StructLayout(Sequential)] partial class and partial struct with regards to ordering?

[TheProxyRE]

That gets me wondering: what happens with [StructLayout(Sequential)] partial class and partial struct with regards to ordering?

Ok Structs are by default Sequential and I did a small test and seems like it just concatenates
(Didn't correctly screenshot if you see mdtokens with names you can see real order)

and the same goes for class with forced sequential

so I guess there are already some rules regarding finalized struct/class after partial concatenating

[Rekkonnect]

In the case of structs, ordering matters significantly less. The actual field offsets are not a concern for 99.9% of the cases, and if they are, you just use the & operator to get their address.

For enums, on the other hand, a single change on one of the partial declarations could alter the entire enum values, unless explicitly declared. Each partial declaration of an enum must begin with a specified value, it's a no-brainer. Imagine making such an adjustment on a public API without knowing which enum you can freely insert a new member without pushing back other values.

I'm overall fine with the idea, for long as there's some enforcement for user handling on the declared fields' values. You can't let the compiler just randomly pick the partial declaration order (in the case of multiple files), let alone pick the values for you. When you're implicitly declaring field values, you know that they start from 0 on the first one, and then add 1 to the next. Not the case for partial declarations though.

[brabebhin]

I still don't see a use case where you'd need partial enums. Even for large enums, assuming you need those often, and don't like any alternatives, you'd still want to write them into a single file, just to reduce maintenance overhead. Partial classes are already considered an anti pattern outside of designer generated classes. I don't think people will rush over to using partial enums.

[levicki]

@brabebhin

I still don't see a use case where you'd need partial enums.

I am a bit late to this discussion, but I do see a use case.

Let's say you use an enum for returning an error code, and you have an enum definition for errors which are common to all hardware devices in the MyHardware.Common namespace.

Now, each hardware device class within MyHardware.Devices namespace has its own error range, and you will hopefully agree that each hardware device class should own their error codes, right? But you still want to have a common error return type for all methods of all hardware device classes to avoid casting or special-casing, so what do you do?

The only thing you can -- you put all error codes for all hardware devices into a gigantic MyHardware.Common\AllErrorCodes.cs, and every time you add a new hardware device class you need to update that file and if your team does not own the error code list you have to submit a request for it to be updated instead of doing it yourself.

This example might sound oddly specific, but it can be translated to other areas -- say web server api controllers for different transaction types, etc.

So, having a partial enum would, in my opinion, make a lot of sense.

Also, I agree with @RikkiGibson that ordering could be a problem and I propose that for enum to be marked partial you have to specify the starting element index, or to have an attribute (say [EnumOffset(1000)]) which can override that too.

[mellamokb]

This idea hasn't seemed to get much traction, but I did just have a use case today. We have an enum that is auto-generated from a database table using a T4 template. I realized I wanted to add a custom entry to the enum not sourced from the database. In this case it would be useful to have a partial enum with the additional item specified in a separate non-generated file. Similar to the reasoning for partial classes with auto-generated code. Obviously it is simple enough workaround to tweak the T4 template to generate the extra item, but a partial enum would be useful here.

[HudsonAkridge]

Same here. We have clients generated from NSWAG and need to extend the enum values defined in the swagger.json to include a couple of additional enums. They're all explicitly ordered so there's no chance of collisions.

A partial on enum would be a pretty big help.

[RikkiGibson]

The main issue in my view is that partial enums with automatic values (i.e. no initializers for the members) have a file ordering dependency. You can get weird ordering-dependent behavior with static field initializers, but it's a bit harder to do by accident:

partial class C
{
    static int F1 = 0;
}

partial class C
{
    static int F2 = F1 + 1;
}

partial class C
{
    static int F3 = F2 + 1;
}

In the above sample if the partial declarations get unexpectedly reordered then the values in the fields may change. That's a pre-existing/shipped behavior. Imagine a similar partial enum:

partial enum E
{
    E1
}

partial enum E
{
    E2
}

partial enum E
{
    E3
}

To resolve this it might be reasonable to require the first member in a given partial enum declaration to have an initializer. That prevents this kind of cross-file ordering dependency from occurring, but it could be inconvenient if adding a new member to a "previous" declaration required explicitly updating the initializer on the "later" declarations.

[TheProxyRE]

Im not sure if i followed this up but if you do care about values (or just order) of certain enums than ye you should declare first value of each partial enum (where others would follow up). But in most cases you do not care what are values under the hood for enums.

I do not think that values itself should be random but it can follow sort rules for eg: FileName and line number (in case of multiple enums in same file).
And i guess assigning values should work same as if you concat all enums fields by sort rules above and put them in single lowered enum instance for example:

File1.cs

public partial enum TestEnum
{
    a = 2,
    b,
}

public partial enum TestEnum
{
    c,
    d,
}

File2.cs

public partial enum TestEnum
{
    g,
    h = 8,
}

public partial enum TestEnum
{
    e,
    f,
}

When TestEnum is lowered it should look like this:

public partial enum TestEnum
{
    a = 2,
    b,    //3
    c,    //4
    d,    //5
    g,    //6
    h = 8,
    e,   //9
    f,    //10
}

And just to note all existing enum rules should apply to this lowered version of enum, and in case of error compiler should just fix up error message to show partial enum line of code instead of lowered enum

[Rekkonnect]

This makes things way too implicit, who guarantees file order? What if you rename a file and suddenly you break order? Or what if the files are not even ordered by name?

There can indeed be cases where you really don't care about the order of the values, though I'd rather have a way to explicitly express that order doesn't matter as long as the values are distinct.

[TheProxyRE]

@alfasgd

This makes things way too implicit, who guarantees file order? What if you rename a file and suddenly you break order? Or what if the files are not even ordered by name?

Compiler would be the one to ensure that file names (full paths to be exact) are used

There can indeed be cases where you really don't care about the order of the values, though I'd rather have a way to explicitly express that order doesn't matter as long as the values are distinct

As i stated above you can assign first value of each partial enum and others would follow up (this is how enums currently work)

Another thing that would be file agnostic is to add priority custom attribute, that would provide third sorting parameter.
And just to note this priority would be fist sorting parameter, than full path and last would be File Line

//File1.cs

public partial enum Code
{
a = 101,
b,
}

public partial enum Code
{
g,
h,
}

[PartialPriority(-10)]
public partial enum Code 
{
k,
l,
}

//File2.cs

[PartialPriority(10)]
public partial enum Code 
{
e,
f,
}

//File3.cs

[PartialPriority(100)]
public partial enum Code 
{
c = 4,
d,
}

public partial enum Code
{
i,
j,
}

would result in

public enum Code 
{
c = 4,
d,  //5
e,  //6
f,  //7
a = 101,
b,  //102
g,  //103
h,  //104,
i,   //105
j,   //107
k,  //108
l,   //109
}

[MarkPflug]

One odd scenario where a partial enum is useful is for controlling visibility.

If a code generator doesn't explicitly assign visibility, and a user wants to make the enum public, they can do so in a user-owned file.
Generated Foo.g.cs

partial enum Foo {
A=1, B, C, D, E
}

User Foo.cs

public partial enum Foo {}

the difference with enum is that the order of the members matters. To implement this feature the compiler team would have to add new features that would explicitly specify that behavior.

I don't think that's true, if instead they required that the first member of a partial enum was explicitly defined as RikkiGibson suggested above. I could imagine a code generator that owned a specific range of values (1-1000) and allowed the user to extend this with values from a different range.

It seems to me, that any type that is defined in a generated file should be partial to give users the ability to extend/amend what the generator provides.

[Rekkonnect]

This feature could be linked with member visibility, but it would break consistency with other partial type declarations. In the end, some different way to privatize enum members could be considered.

[VWilcox2000]

Not something I would use commonly, but in cases where compile directives / shared projects are used to facilitate progressive migration from legacy to new solutions or for different hardware implementations, I might leverage this to selectively include partial enums base on the current compiler config and the #defines in play -- could also have same enums with different values for say bit-wise use. Don't see it as a high yield feature, but it seems intuitive and simple.

[AartBluestoke]

suggestion for resolving conflicts, to allow different files to offer values out of the (quite large) integer valuespace range:

• the first element of all partial enums must have a value identified.
• It is a compiler error for two different partial enums to offer the same value.

Enums are defined over 'int' by default not 'byte' or 'short', indicating an intent to support enums with vastly more than 255 options.
anything specifying more than 255 options in 1 list probably should consider splitting that list by purpose or some other category.

[HaloFour]

@bernd5

The only downside I see is that this results in unused types (the enum parts) in the assembly...

You could use ConditionalAttribute to exclude them from the final assembly. They would still be visible to the source generator.

[levicki]

@alfasgd

Hopefully I can answer those questions correctly:

Thanks, the only reason I asked @RikkiGibson is because they are a maintainer on this repo. Frankly, I was hoping to get a reason why this is not implemented yet after 3 years despite being so obvious low hanging fruit, and when we might expect it.

According to your answers, it seems that it is just a matter of low priority.

Since you say you implemented it already, did you try sending a PR for review?

[HaloFour]

@levicki

Frankly, I was hoping to get a reason why this is not implemented yet after 3 years despite being so obvious low hanging fruit, and when we might expect it.

No feature is implemented unless someone from the language team decides that it's worth bringing to the design meetings. It doesn't matter how difficult the feature is to implement, the team has to agree as a whole that the feature is one that they want added to the language and that they agree on the design and implementation. No community contribution will be considered without a sign-off on that.

[Rekkonnect]

Since you say you implemented it already, did you try sending a PR for review?

The proposal isn't even championed, it won't be looked at until somebody champions it. That's how things work here. For example, I had implemented some pointer-related features, submitted this PR and it got closed due to the fact that not both proposals were championed, and that the specs are missing.

[CyrusNajmabadi]

Frankly, I was hoping to get a reason why this is not implemented yet after 3 years despite being so obvious low hanging fruit,

This is definitely neither obvious nor low-hanging fruit. And i would find it difficult to pick this item to do over many of the others that are in the repo currently.

[levicki]

No feature is implemented unless someone from the language team decides that it's worth bringing to the design meetings.

So I guess my next question is did someone from the language team even consider it over the past 3 years?

This is definitely neither obvious nor low-hanging fruit.

The fact that someone already implemented it in their private branch without much trouble says otherwise, at least to me. Not to mention that partial already works for other classes and as such enum is quite an obvious target.

And i would find it difficult to pick this item to do over many of the others that are in the repo currently.

Why? I am genuinely curious. It doesn't seem very hard to implement and it would make partial keyword fully orthogonal.

I understand that resources are limited, but at some point a decision has to be made.

I guess what irks me is that those decisions seem to keep being postponed indefinitely and people who submit any feature requests don't get any feedback or closure.

For this one, it's been 3 years, if you won't do it then just say so and be done with it.

Or if you want to do it but cannot do it now, then at least let us know and commit to a timeframe, even if it is "we'll do it in X months/years" or even "we'll consider it for C# version 15.0".

The worst possible thing is silence, it discourages contribution.

[333fred]

Another LDM member may feel differently.

Personally, while I don't necessarily think this is a bad feature request, I think it is very low on my priority list of features to add to the language.

[levicki]

@CyrusNajmabadi

This is not constructive or conducive to discussions here.

That comment wasn't meant as an insult to your team in any way, and I hope that's not how you took it.

It was pointing out (with a bit of exaggerating) the huge responsibility you guys have while being starved for resources -- that one is totally on Microsoft, none of it is on you. While I understand that it is not constructive (more like exasperated venting on my end which you rightfully marked offtopic), to me it also seemed like a fair assessment of a disappointing reality we are in.

Anyway, could you and @333fred please give an example of a feature (or a few) which you consider higher priority than this one? I'd like to get at least a rough idea of what new features are important right now, provided of course that you are at liberty to reveal that.

In any case, thanks for your time and I hope that this feature gets some love in the near future.

[CyrusNajmabadi]

Anyway, could you and @333fred please give an example of a feature (or a few) which you consider higher priority than this one?

Shapes/Roles/Discrinated-Unions

In any case, thanks for your time and I hope that this feature gets some love in the near future.

YW :)

[333fred]

I'd say keep your eyes out for the next few LDM note sessions to see what members of the LDM consider high-priority items.

[levicki]

@333fred Thanks for pointing me in the right direction I found what both of you were referring to.

[perholmes]

Came here because of a use case and trying to solve it without just doing the enum as a bunch of hard-coded constants.

We have a core framework used in a number of apps. That framework has a number of enumerated UI blocking "Flows", and the framework brings about 5 Flow "Levels". The app itself will then define another 50 Levels or so.

In order for the Flow framework to just relate to Levels as a whole, I'd need a partial enum that defined the 5 Levels available in the framework, and an app-specific partial enum for app Levels.

The real problem with partial enums, I think, is that a single enum class can comfortably start at 0 and increase. But who gets to start in a partial enum class? Will my first framework enum value be 0 or 50?

If partial enum classes were implemented, I think the language spec would have to require that a value is assigned to the first enum, and a compiler error thrown if duplicate values are used. I would use this immediately if it existed.

For now, we'll likely just hard-code a bunch of constants and create some kind of convention about which number ranges are used.

[Rekkonnect]

I've created a prototype spec, as I've linked in another comment, which address this issue. You shouldn't rely on implicit initialization rules when dealing with partial enums, because you prefer being explicit about ordering.

[perholmes]

In case it helps anyone, the hack we're going with is to simply let our framework define one enum and the app another enum with another name, and then the class that actually does the work operates entirely on System.Enums.

Type-safety goes out the window, but it could be brought back with multiple overloads of important methods that take each kind of enum and internally cast it to System.Enum and pass it to worker functions. But then the framework can't run unless the app code defines this second enum, which is clumsy. Enum comparisons are then internally done as integers.

It also requires some conventions about which integer ranges are defined in each enum, which seems like a problem that doesn't go away with partial enums. And this is actually already annoying.

But some variation of partial enums is the only game in town for enums that are defined in a common code base and need to be extended by the client app. It's a pretty sore thumb that enums are 100% unextendable.

[Rekkonnect]

It also requires some conventions about which integer ranges are defined in each enum, which seems like a problem that doesn't go away with partial enums. And this is actually already annoying.

Since you've already given up on elegance, you can tackle it by defining some attributes on the enum types and reading semantics from there, at least that's the path I'd resort to

[perholmes]

Since you've already given up on elegance,

Maybe a bit cynical? I'm doing something I can do now. And I'm in Unity, so even if C# gains this feature, I won't see it for another 5 years. But yes, I can do attributes. I can also just make a convention, which I did. It's also possible to use attributes in ways that don't protect myself from myself, so I have to be disciplined either way.

[levicki]

There's another simple trick that can be used to "emulate" enums without type safety (and without actually using any System.Enum functionality).

It's really a hack:

public struct WM
{
	public const UInt32

	CREATE		= 0x0001,
	DESTROY		= 0x0002,
	CLOSE		= 0x0010,
	QUIT		= 0x0012,
	USER		= 0x0400,
	APP		= 0x8000;
}

And you can even reference those values in a different struct:

public struct WFS_EVENT
{
	public const UInt32
	
	EXECUTE		= WM.USER + 20,
	SERVICE		= WM.USER + 21,
	USER		= WM.USER + 22,
	SYSTEM		= WM.USER + 23;
}

But at least it makes the code readable.

I can't believe that we still don't have partial enums in 2023 and have to resort to stuff like this.

[The-Futurist]

Very occasionally I've had situations where I wanted to add more entries to an existing enum that is not part of the source code. The way I solved it was to create a new enum whose first member had a value higher than the last member of the other enum.

So this might be doable using the existing : inherit symbol:

public enum BaseBitops
{
   And,
   Or,
   Nand,
   Nor
};

then be able to code:

public enum GeneralBitops : BaseBitops
{
   Exor,
   ExNor,
   RotateLeft,
   RotateRight
};

Then

   InsertOperations(GeneralBitops.Nand, GeneralBitops.RotateLeft);

This might possibly have some potential...?

[perholmes]

objective problem statement

That has been provided over and over, but here goes again:

A library uses enums for modes or settings. Library is used by multiple apps. Library provides basic enums, like "None" or "All", and each app then provides the bulk of the enums to flesh out the behavior of the library. But this is impossible, because the library categorically owns the enum. There's no way to extend the enum.

A partial enum would allow the library to define the basic values, and the app could provide the remaining enums.

Our use case is a UI blocking framework, so that any longer async process in the app "owns" the UI and can't be interrupted. When a "Flow" is going, any other Flows that want to start hold on async until the UI is released. Then the highest priority Flow is selected and allowed to run.

The library provides 4-5 basic enums for things like crash handling, update checking, account flows etc, but then the app provides 50 more for everything it does.

Because partial enums don't exist, and without hacking the language, the only options are:

• Manually defining a lot of constants. To get type-safety, they could be done under a custom Int type. But no protection against duplicates.
• Using System.Enum inside the framework. Then we've defined two enums, the one provided by the library and the one provided by the app. A lot of casting turns this into System.Enums and Int32s inside the library. Better than constants, but no duplicate protection and no type safety. You could send any enum by accident and get unexpected behavior.

A partial enum framework would allow C# to reason about all the values and stay type safe. It would require that a starting value is defined for each partial enum, so there's no competition between the partial enums.

Partial enums would solve a clear use case that has no other clean solution.

[HaloFour]

@perholmes

A partial enum would allow the library to define the basic values, and the app could provide the remaining enums.

I'll note that I think a lot of the confusion is that partial already means something very specific in C#, and cannot exist across assembly boundaries. So if the goal is to be able to take an enum defined in one assembly and extend it for a specific use case in another assembly, the partial keyword cannot apply. I only say that as using the existing verbiage creates an expectation around the implementation and behavior of a feature, so perhaps trying to find a more generic term would be helpful here in avoiding confusion.

I'll note that rereading the OP, I think the intent of this proposal is actually to add partial enums, where each part is defined in the same assembly and the compiler emits a single enum type.

[perholmes]

Hi,

Valid point in a lot of cases. In our case, the common code is a Git submodule and in the same assembly, so this didn't occur to me.

I'm somewhat indifferent about the implementation. The goal is ultimately just to be able to add values to an enum created by code not under your control, and without forking and hacking it.

But it does strike me as a frustrating limitation that partial can't extend across assembly boundaries, forcing you to do inheritance to augment a library class, and without any guarantee that the library itself will call your derived class. Allowing partial to be more of a promiscuous feature would allow you to side-load on classes or enums or whatever, but keeping your modifications separate. All too often, you're forced to fork and become responsible for a 3rd party library just because you want to change one line. If partial could extend further than the assembly, this would universally be my preferred way of injecting my changes into library code. It could become culture that library classes are partial or you're considered a jerk, and then people have a way to side-load better functionality.

That, or an "impose" keyword that does a partial, but only from the outside. But I'm spitballing, and I'm not the right person to suggest a harmonious implementation.

[HaloFour]

The supported approaches to augmenting existing types would be through inheritance or extensions, the latter of which is going through a bit of an overhaul. I wonder if extensions might be able to accommodate the concept of taking an existing enum and extending it to support additional members. However, that would be external to the library code and only visible to your own code or code that consumes your extensions.

As for modifying type definitions in other assemblies, I don't know if there'd be much appetite for supporting something like that in the C# language or the runtime. I imagine the argument would be that it breaks encapsulation since you're not affecting the internal implementation of that library rather than interfacing with its public API surface. Even something as seemingly benign as adding a new member to an existing enum type could have far reaching consequences if that library, or some other dependency, interprets that enum via reflection and is unable to accommodate the change that you made. Changes to implementation details now can break that integration whereas that should never really be observable to external consumers of the library.

[miyu]

partial enum would enable a Source Generator to add an attribute to an enum type.

For example, with my serializer:

// MyEnum.cs
public partial enum MyEnum { A, B, C }

// MyEnum.Generated.cs
[TypeId(123)]
[Guid("x")]
public partial enum MyEnum { }

This behavior would be match that of partial for classes and structs. The disparity in support for enums was quite surprising to me.

Additionally, though not useful to me, partial enum would allow a source generator to set the backing type of an enum.

[radobot]

To provide another real-world use-case for this feature I would like to mention Vulkan API.

It has multiple enums (for example VkResult) that get extended with new versions and extensions.
It would be really useful if enums could be split across multiple files so that new members can be added by simply creating a new file without needing to touch any existing files.

For example:

// Core/Version1.0.cs
public partial enum Result {
	ErrorUnknown = -13,
	ErrorFragmentedPool = -12,
	ErrorFormatNotSupported = -11,
	ErrorTooManyObjects = -10,
	ErrorIncompatibleDriver = -9,
	ErrorFeatureNotPresent = -8,
	ErrorExtensionNotPresent = -7,
	ErrorLayerNotPresent = -6,
	ErrorMemoryMapFailed = -5,
	ErrorDeviceLost = -4,
	ErrorInitializationFailed = -3,
	ErrorOutOfDeviceMemory = -2,
	ErrorOutOfHostMemory = -1,

	Success = 0,
	NotReady = 1,
	Timeout = 2,
	EventSet = 3,
	EventReset = 4,
	Incomplete = 5,
}

// Core/Version1.1.cs
public partial enum Result {
	ErrorInvalidExternalHandle = -1000072003,
	ErrorOutOfPoolMemory = -1000069000,
}

// Extensions/KHR/Swapchain.cs
public partial enum Result {
	ErrorOutOfDateKHR = -1000001004,
	SuboptimalKHR = 1000001003,
}

// Extensions/NV/GLSLShader.cs
public partial enum Result {
	ErrorInvalidShaderNV = -1000012000,
}

In this specific use-case every enum member has assigned value so there is no ambiguity about member values and load order doesn't matter. I think it would be a reasonable compromise to require every member of a partial enum to have assigned value or at least the first member of every block.

[layolayo]

We also have a requirement for partial enums. We are looking to hold a base class holding some standard enums, then as we superclass from that class we add in specific enums for those classes.

The allocation of numbers are specific and would be defined - but these numbers could be similar between superclasses, though the enum reference is different.

Base Class

  public partial enum TypeRef
  {
      UndefinedThingType = 0,
      Application = 1,
      Company = 2,
      SystemUser = 5,
      Role = 10,
      Securable = 12,
      Login = 15
}

SuperClass 1

  public partial enum TypeRef
  {
  Site = 100,
  SiteLocation = 105,
  SystemLocation = 108
}

SuperClass 2

  public partial enum TypeRef
  {
  Project = 100,
  Document = 105,
  DocumentType = 108
}

[HaloFour]

That doesn't seem like partial enums as much as it sounds like some kind of enum inheritance.

[layolayo]

If that is possible! that is great, I'm off to check - I only found the thread as I was looking for a solution

[XeonG]

this would be useful to expand on an partial enum.. but would it work if the enum was in another name space?

[Rekkonnect]

I would expect this to work in the same way other partial declarations work; only within the same assembly. A different namespace would contain an entirely different type (A.B.C is different than A.B).

[UsernameNotProvided]

I would like to contribute my two cents because I'm running into needing this. Like someone said for error handling. I want to handle the errors in my application in a uniform way, but I don't want one giant enum to dump all the codes in because it would make them harder to manage (and would expose error codes to modules that shouldn't use that particular code). After reading a lot of comments in this thread I think partial enum isn't the way to go because of various limitations, pitfalls, and complexities. If it was there was probably a solution offered for it in the past five years since this item has been open.

Let's say you have these three enums:

public enum Animals { dog, cat, gerbil }
public enum Things { car, house, dumpster }
public enum Foods { pizza, pasta, fries }

You can use these enums in various places where they make sense. But in some places you would prefer that they were one large enum. For that I propose the following syntax:

public new enum Stuff {
  using Animals,
  using Things,
  using Foods
} 

There are two things that make this not a regular existing enum, and those two things are keywords already part of the language and already used in different ways in different places.

"new" is used to create new instances, but also to shadow members in base classes (forgive me if shadow isn't the right word).
"using" is used to include namespaces, but also as the using block that disposes objects when they go out of scope.

So the use of those two keywords in a different context wouldn't pose a problem and they make it very obvious that this isn't like the existing regular enum while keeping the same simple declaration that a regular enum has.

It would of course be possible to use namespaces as well:

public new enum Stuff {
  using VendorNamespace.Animals,
  using MyProject.SomeExtraName.MoreNameToFollow.Things,
  using Foods
} 

They "as" keyword which is currently used a type conversion operator could be repurposed here to resolve conflicts in the name of enums:

public new enum Stuff {
  using VendorNamespace.Animals as FluffyAnimals,
  using OtherVendorNamespace.Animals as SpikeyAnimals,
  using MyProject.SomeExtraName.MoreNameToFollow.Things,
  using Foods
} 

To "new enum" type would behave like a regular enum when it is cast to a different data type, for example:

Stuff myStuffValue;
int value = (int)myStuffValue;

But in code the syntax to assign a value would be slightly different (but logical):

Stuff myPet = Stuff.FluffyAnimals.dog;

Because the enum members would always be fully qualified duplicate names in the used enums wouldn't pose a problem.
To deal with conflicts in numbering the "new enum" type would allow to set the beginning of the range for each included enum:

public new enum Stuff {
  using VendorNamespace.Animals as FluffyAnimals = 10000,
  using OtherVendorNamespace.Animals as SpikeyAnimals = 20000,
  using MyProject.SomeExtraName.MoreNameToFollow.Things = 30000,
  using Foods = 40000
} 

Values assigned by the developer or the compiler to the enum members of the used enums would be added to the start of the range that is set on the "new enum". This would make that...

int myDinner = (int) Stuff.Foods.fries

...has an unique value while the compiler could still know that these are true:

((Stuff) 40002) == (Foods) 2
((Stuff) 40002) == Foods.fries
Stuff.Foods.fries == (Foods) 2
Stuff.Foods.fries == Foods.fries

That might seems strange but there is nothing preventing a coder from currently doing:

((int) Food.fries) == ((int) Animals.gerbil)

And getting a result of true on that. The compiler could handle casting to and from the "new enum" and the various enums it uses, but just like with regular existing enums once you cast to number data types you are taking the steering wheel and should be paying attention.

The existing Enum class and other ToString methods / reflection classes would work with this "new enum" like with regular enums but with the understanding that things like...

string name = Enum.GetName<Stuff>(Stuff.Foods.fries);

... would produce the fully qualified name as "Foods.fries".

The "new enum" would fall in the category of things that you shouldn't worry about if you don't know that it exists, but a valuable tool to have when you need it.

I think this syntax would satisfy and perhaps exceed the expectations / needs of the persons asking for a partial enum. The "new enum" wouldn't be limited to the same namespace or even the same assembly that partial would be limited to. You could create a "new enum" that includes any enum (and even other "new enum") that isn't declared as private or protected in any assembly.

Looking forward to feedback, suggestions, or questions.

[Rekkonnect]

I only skimmed through this and I'm pretty sure this falls under the "better have as a domain-specific source generator". I find this ultra niche for a general language feature, and since we have the ability to write source generators for such cases, my personal opinion tends to that direction.

[UsernameNotProvided]

I only skimmed through this and I'm pretty sure this falls under the "better have as a domain-specific source generator". I find this ultra niche for a general language feature, and since we have the ability to write source generators for such cases, my personal opinion tends to that direction.

Enums are a design time functionality to aid developers in using the correct values, just like constant strings are a design time functionality to prevent bugs with magic strings. The proposed syntax would extend enum but in itself act as enum during development. I don't think a source generator is a replacement for that. I'm also not sure what the generated code would look like to make each member of the generated class behave as the value of an enum. That would probably mean at least one class per enum value. That wouldn't be good for runtime performance for something that should be essentially "compiled away".

[kmoulins]

yet another use case: I'm writing a library which is supposed to work with any other languages and support user generated values (users being other devs using the tool), so storing as an integer but having an enum (with explicitly defined values, which imo a partial enum or whatever syntax is used could require, erroring if there's a duplicate) makes a lot of sense. (as I want to write a reference implementation with custom things)

declaring custom flags is also something you might want to do (and one where partial/inherited enums would be nice for purposes of toString with [flags] giving all the flags)

as a workaround, using a dictionary<int, string> (maybe generated) does the job, though it's sensitive to typos and not as easy to find by name if you need specific things treated differently, and probably slower, using it with a template to generate an enum might work however.

class a {
  public static Dictionary<int,string> Foo =new  Dictionary<int,string>(){
    {0,"foo"},
    {1,"bar"}
  };
}
class b {
  public static Dictionary<int,string> Foo = new  Dictionary<int,string>(){
    {2,"foo1"},
    {3,"bar1"}
  }.Concat(a.Foo).ToDictionary<int, string>();
}

enums are happy to take a value that's not declared (most likely intended, because flags), and since in my case I'm just using 2 enums, another option is to simply cast one to the other as needed.

    public enum Foo //assume this comes from the library. 
    {
        foo = 0, bar=1
    }

    public enum PartialFoo
    {
        foo1 = 2, bar1=3
    }
    
    Foo a = 3 
    if((PartialFoo) a==PartialFoo.bar1){
    // do something
    }

a slightly more involved solution is to write a class implementing IEquatable, operator == and != (with itself, int, and your enums), has a method to get the name corresponding to an int from the enums you want, and implements toString for all flags.

[timcassell]

It sounds like you're looking more for enum extensions than partial enums. #3491 Partial is only for the local assembly.