Proposal: Generic Specialization

[benaadams]

Related: "Adding a 'static if' construct to support generic specialization" #8871

Currently generics create a duplicate code path for structs and share one for classes

This can be used to specialize the generic type for individual structs using typeof which are then removed at jit time to make branchless paths; System.Numeric.Vectors is probably the most extreme example of this.

However even this advantage for structs can lead to oddities (as well as very large functions); such as casting values through object to convert T to valuetype

public unsafe Vector(T value) : this()
{
    if (Vector.IsHardwareAccelerated)
    {
        if (typeof(T) == typeof(Byte))
        {
            fixed (Byte* basePtr = &this.register.byte_0)
            {
                for (int g = 0; g < Count; g++)
                {
                    // Cast via object
                    *(basePtr + g) = (Byte)(object)value;
                }
            }
        }
        else if (typeof(T) == typeof(SByte))
        {
            fixed (SByte* basePtr = &this.register.sbyte_0)
            {
                for (int g = 0; g < Count; g++)
                {
                    // Cast via object
                    *(basePtr + g) = (SByte)(object)value;
                }
            }
        }

Proposal

Allow specialist implementations of a Generic type to be pre-defined; including for class types

public struct GenericType<T> : IEquatable<GenericType<T>>, IFormattable {}
public struct GenericType<byte> : IEquatable<GenericType<byte>>, IFormattable {}
public struct GenericType<string> : IEquatable<GenericType<string>>, IFormattable {}

If a specific generic type is specified this will take precedence over the T version; otherwise will work as now.

Bonus Round

Allow templating "specialization" where the overload is automatically generated

public struct GenericType<TList> 
    : where TList : IList<int>
    : specialize List<int>, int[]

Where the specializations will automatically be generated for those class types to take advantage of inlining etc

Questions

• Can the specialist type be partial or inherited in some way so it can choose the methods it overrides?
• Specialisation of generic functions? e.g.

public static EqualityComparer<T> Default { get; }
public static EqualityComparer<string> Default { get; }
public static EqualityComparer<byte> Default { get; }

/cc @jamesqo @stephentoub @jkotas @jaredpar

[jamesqo]

Oh yeah, this would definitely be nice if we could have it. (i.e. we could probably remove the _hashCode field from all Dictionary buckets if int is the key.) It would probably require runtime support, though.

[bbarry]

But in case of type substitution you will not get the specialized type without clr support or nasty code generation.

You would also not get nonvirtual calls.

I wonder if it could be done with an abuse of partial...

public partial struct Vector<T> : IEquatable<Vector<T>>, IFormattable where T : struct
{
    public unsafe void CopyTo(T[] destination, int startIndex)
    {
        ...
        if (Vector.IsHardwareAccelerated)
        {
            AccelCopyTo(destination, startIndex);
        }
        else
        {
            InternalCopyTo(destination, startIndex);
        }
    }

    private unsafe partial AccelCopyTo(T[] destination, int startIndex); // no implementation => throw if called
    private unsafe partial InternalCopyTo(T[] destination, int startIndex);
}

public partial struct Vector<Byte>
{
    private unsafe partial AccelCopyTo(Byte[] destination, int startIndex)
    {
        fixed (Byte* destinationBase = byteArray)
        {
            for (int g = 0; g < Count; g++)
            {
                destinationBase[startIndex + g] = this[g];
            }
        }
    }
    ...
}
...

[aluanhaddad]

I've wanted to see something like this for a long time. This would enable nice optimizations without fragmenting a clean API.

[gafter]

We are now taking language feature discussion in other repositories:

• https://github.com/dotnet/csharplang for C# specific issues
• https://github.com/dotnet/vblang for VB-specific features
• https://github.com/dotnet/csharplang for features that affect both languages

Features that are under active design or development, or which are "championed" by someone on the language design team, have already been moved either as issues or as checked-in design documents. For example, the proposal in this repo "Proposal: Partial interface implementation a.k.a. Traits" (issue 16139 and a few other issues that request the same thing) are now tracked by the language team at issue 52 in https://github.com/dotnet/csharplang/issues, and there is a draft spec at https://github.com/dotnet/csharplang/blob/master/proposals/default-interface-methods.md and further discussion at issue 288 in https://github.com/dotnet/csharplang/issues. Prototyping of the compiler portion of language features is still tracked here; see, for example, https://github.com/dotnet/roslyn/tree/features/DefaultInterfaceImplementation and issue 17952.

In order to facilitate that transition, we have started closing language design discussions from the roslyn repo with a note briefly explaining why. When we are aware of an existing discussion for the feature already in the new repo, we are adding a link to that. But we're not adding new issues to the new repos for existing discussions in this repo that the language design team does not currently envision taking on. Our intent is to eventually close the language design issues in the Roslyn repo and encourage discussion in one of the new repos instead.

Our intent is not to shut down discussion on language design - you can still continue discussion on the closed issues if you want - but rather we would like to encourage people to move discussion to where we are more likely to be paying attention (the new repo), or to abandon discussions that are no longer of interest to you.

If you happen to notice that one of the closed issues has a relevant issue in the new repo, and we have not added a link to the new issue, we would appreciate you providing a link from the old to the new discussion. That way people who are still interested in the discussion can start paying attention to the new issue.

Also, we'd welcome any ideas you might have on how we could better manage the transition. Comments and discussion about closing and/or moving issues should be directed to #18002. Comments and discussion about this issue can take place here or on an issue in the relevant repo.

---

Type classes would support this feature request, but with a completely different and typesafe syntax, and are under consideration at dotnet/csharplang#110