[API Proposal]: Type.GetEnumValuesAsUnderlyingType

Background and motivation

The existing Type.GetEnumValues API returns a System.Array that is of the given enum type (i.e. SomeEnum[] when called on typeof(SomeEnum)). This makes implementing the API challenging when the enum array cannot be created. There are multiple reasons why the enum array might not be possible to create:

We're in a reflection-only context such as MetadataLoadContext:

runtime/src/libraries/System.Reflection.MetadataLoadContext/src/System/Reflection/TypeLoading/Types/RoType.cs

Line 289 in d6e8686

public sealed override Array GetEnumValues() => throw new InvalidOperationException(SR.Arg_InvalidOperation_Reflection);
We're on a platform where runtime codegen (or universal shared code) is not available.

It would be good to have API that can work in these contexts by returning an array of the underlying type (i.e. int[] for typeof(SomeInt32Enum).

API Proposal

namespace System;

public abstract class Type
{
    public virtual Array GetEnumValuesAsUnderlyingType();
}

API Usage

foreach (var value in typeof(SomeEnum).GetEnumValuesAsUnderlyingType())
    Console.WriteLine(value);

// Prints:
// 0
// 1
//
// As opposed to:
//
// SomeEnumValue1
// SomeEnumValue2

Alternative Designs

Allow implementers to not satisfy the contract

The implementation of the existing Type.GetEnumValues could just return the underlying array directly since the signature is just System.Array. But that is probably pretty breaking - see #72236 (comment) for samples.

Write more code

Can be expressed in a less performant and more verbose way already:

foreach (var f in typeof(DayOfWeek).GetFields(BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Static))
{
    Console.WriteLine(f.Name);
    Console.WriteLine(f.GetRawConstantValue()); // This returns the field value as boxed underlying type
}

Risks

No response

Would this API return an array of the underlying type in all cases or only when it's not possible to figure out the type under AOT?

Would this API return an array of the underlying type in all cases or only when it's not possible to figure out the type under AOT?

In all cases. Switching the array type around would be a compat problem in the same sense as returning int[] from the existing API. No reason to introduce it.

Does it make more sense to have the API on Type or in Enum? Currently APIs are in both of those places.

For the MetadataLoadContext use case, the Type API is the one that makes sense.

I'll leave it up to the API review board whether it makes sense to add a shortcut on Enum for discoverability.

@MichalStrehovsky

@MichalStrehovsky This is marked blocking. Be sure to add a milestone (7.0 or Future) as well. Thanks!

@MichalStrehovsky

@MichalStrehovsky This is marked blocking. Be sure to add a milestone (7.0 or Future) as well. Thanks!

Marked for 7.0, thanks for spotting!

@lambdageek

/cc @lambdageek

Video

Let's add a corresponding method on Enum as this would maintain the parity with the existing methods that exist on both Type and Enum.
Let's also add a generic version for parity

namespace System;

public partial class Type
{
    // Existing enum related methods:
    //
    // public virtual string? GetEnumName(Object);
    // public virtual string[] GetEnumNames();
    // public virtual Type GetEnumUnderlyingType();
    // public virtual object[] GetEnumValues();

    public virtual Array GetEnumValuesAsUnderlyingType();
}

public partial class Enum
{
    public static Array GetValuesAsUnderlyingType<TEnum>() where TEnum: struct, Enum;
    public static Array GetValuesAsUnderlyingType(Type type);
}

Navigation Menu

Repository navigation

[API Proposal]: Type.GetEnumValuesAsUnderlyingType #72498

Background and motivation

API Proposal

API Usage

Alternative Designs

Allow implementers to not satisfy the contract

Write more code

Risks

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[API Proposal]: Type.GetEnumValuesAsUnderlyingType #72498

Description

Background and motivation

API Proposal

API Usage

Alternative Designs

Allow implementers to not satisfy the contract

Write more code

Risks

Activity

MichalPetryka commented on Jul 20, 2022

MichalStrehovsky commented on Jul 20, 2022

MichalPetryka commented on Jul 20, 2022

MichalStrehovsky commented on Jul 20, 2022

GrabYourPitchforks commented on Jul 20, 2022

MichalStrehovsky commented on Jul 20, 2022

marek-safar commented on Jul 22, 2022

terrajobst commented on Jul 26, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions