[API Proposal]: Need a Reliable Way to Check to See if a Type is a Record Class

[RealDotNetDave]

Background and motivation

In .NET, the Type class provides various methods to determine whether a type is a value or a class type. Through my benchmarking work with .NET, I've discovered that the performance characteristics of these types can vary significantly. Additionally, as discussed in detail in my article (link below), performance differences also exist between record types, specifically record classes.

Given these variations, it's important to have a reliable way to identify if a type is a record class. This distinction is critical for writing efficient generic methods that can handle value types, classes, and record types differently.

Currently, I am using the following code to check if a class is a record type, but I'm looking for a more robust and reliable approach.

var member = objType.GetMethod("GetHashCode");
if (member != null && member.GetCustomAttribute<CompilerGeneratedAttribute>() != null)
{
    return TypeOfType.Record;
}

https://dotnettips.wordpress.com/2021/02/26/everything-you-want-to-know-about-the-record-type-in-net-5-but-were-afraid-to-ask/

API Proposal

public abstract class Type : MemberInfo, IReflect
{
    public bool IsClass { get; }
    public bool IsValueType { get; }
    public bool IsRecordClass {get; }
}

API Usage

public static TypeOfType GetTypeOfType([NotNull] this object obj)
{
    var objType = obj.GetType();

    if (objType.IsValueType)
    {
        return TypeOfType.Value;
    }
    else if (objType.IsClass)
    {
        return TypeOfType.Reference
    }
    else if (objType.IsRecordClass)
    {
        return TypeOfType.Record;
    }

    return TypeOfType.Unknown;
}

Alternative Designs

No response

Risks

None that I can think of since this will be a new method added to the Type type.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-reflection
See info in area-owners.md if you want to be subscribed.

[huoyaoyuan]

The concept of record doesn't exist at runtime. It's just a convention used by C# compiler.

Additionally, as discussed in detail in my article (link below), performance differences also exist between record types, specifically record classes.

It's mostly incorrect. The performance characteristics isn't determined by it category of declaration, but the way they implemented the conventions.

For example, the concept of "clone" doesn't exist for arbitrary class type. An clumsy implementation with reflection will be obviously slow. Value types have fallback implementation of equality and hash code, which are far from ideal.

Record types are just usual classes or structs (with record struct) with conventions implemented. You will get the exact same performance characteristics if you implement the same conventions in regular class or struct. Types in F# are implementing the conventions in different ways, results in different default performance characteristics.

Moreover, it's intentional to make records not distinguishable with regular types. See discussions in dotnet/csharplang#39 (comment) dotnet/csharplang#39 (comment) and related issues.

[Clockwork-Muse]

Given these variations, it's important to have a reliable way to identify if a type is a record class. This distinction is critical for writing efficient generic methods that can handle value types, classes, and record types differently.

You haven't explained what actual purpose you'd use this method for - what concrete difference it would make in your code.

The only thing that would be available "globally" would be Equals/GetHashCode/ToString, but knowing the type of the object at the library consumption layer isn't all that helpful - you still actually have to call those methods, so you'd still suffer whatever "performance penalty" you're trying to avoid.

[dotnet-policy-service]

This issue has been marked needs-author-action and may be missing some important information.

[steveharter]

Closing; C# record types are either standard classes or value types with generated members so there is not an accurate way to check if the type was based on a record. For the original case on perf, individual checks for constructor overloads and member overrides would be a better approach as it would also work with non-record types as well.