Automatic implementation of IBinaryInteger<self> for enums

Open
#112,819 3 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
csharp
Domain
compilers

Research direction

Start with issue #112819 and investigate how enum types, IBinaryInteger, and compiler/runtime capability checks are currently handled. Determine the design needed for automatic support, including formatting, parsing, and numeric conversions. Done means the behavior is specified and implemented with coverage for supported and unsupported target runtimes.

Written by the indexing model from the issue text.

Description

area-System.Runtime

There's only one thing holding back code such as the below from working right now, and it's that enums do not implement IBinaryInteger<self>:

static T ConsumeEnumValue<T>(ref ReadOnlySpan<byte> buffer, bool isUnsigned) where T : unmanaged, Enum, IBinaryInteger<T>
{
    var value = T.ReadLittleEndian(buffer, isUnsigned);

    unsafe { buffer = buffer[sizeof(T)..]; }

    return value;
}

Has automatic implementation of this interface this been considered, similar to how the runtime implements IReadOnlyList<T> on T[]? IBinaryInteger<T> for .NET enums seems like perfect fit. It would enable generic specialization without writing out a lot of manual reflection code to detect and handle each underlying int size separately. This would also enable enums to participate in all existing generic numerics code.

The compiler would have to detect the runtime capability similarly to how it detects whether the targeted runtime supports native integers. If the targeted runtime does not support it, then it would be a compile error to use a concrete enum type as the type argument to a type parameter constrained : Enum, IBinaryInteger<T>.

It would probably not be desirable for an emitted enum type to explicitly implement this interface in general because the implementation would generally be exactly the same per underlying integer type, and that could be a lot of metadata repetition.

This would only apply to enums whose underlying type implements IBinaryInteger<T>.

Most of the implementation would simply be reusing the IBinaryInteger<T> implementation for the underlying integer type. The exceptions would be:

  • Formatting and parsing to and from chars, which would unify with existing enum formatting and parsing logic.
  • TryConvertTo/TryConvertFrom implementations would allow converting to and from the underlying integer type, so that ulong.CreateTruncating(anyEnumValue) could work and vice versa.
Dominant language
C#
Stars
18.3k
Forks
5.6k
PR metrics pending

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dotnet/runtime

All issues in dotnet/runtime

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.