[Proposal] Generic properties

[differentrain]

Summary

This feature is just like generic method, and often used by low-level developers.

Motivation

Consider a Union in C language.
In modern C#, It is very easy to implement a type plays the same role as Union.
e.g.

struct Union32
{
    private unsafe fixed byte _buffer[32];

    public readonly ref T GetValue<T>() where T : unmanaged
    {
        unsafe
        {
            fixed (void* p = _buffer)
                return ref Unsafe.AsRef<T>(p);
        }
    }

    public void SetValue<T>(in T value, int startIndex = 0) where T : unmanaged
    {
        ref T t = ref GetValue<T>();
        t = value;
    }
}

It is not concise enough for invoker, so how about using generic properties?

struct Union32
{
    private unsafe fixed byte _buffer[32];
 
    public T Value<T> where T : unmanaged
    {
        get
        {
            unsafe
            {
                fixed (void* p = _buffer)
                    return Unsafe.AsRef<T>(p);
            }
        }
        set
        {
            unsafe
            {
                fixed (void* p = _buffer)
                {
                    ref T t = ref Unsafe.AsRef<T>(p);
                    t = value;
                }
            }
        }
    }
}

Design

Generic properties will never support auto-implemented properties.

This feature is dependent on additional logic provides ways to access shared object.

A Generic property may have a set accessor and a get accessor.

public T Value<T>
{
    get => // todo
    set => // todo
}

A Generic property may only have a get accessor.

public ref T Value<T> where T : unmanaged
{
    get
    {
        / /todo
    }
}

Obviously, in some case we can write this code:
public T Value<T> where T : unmanaged => // todo

Exploration: every accessor uses different constraint

I have no idea about it, and I don't know if it is useful.

public T Value<T>
{
    get  // T has no constraint on get accessor.
    {
        // todo
    }
    set where T : unmanaged => // todo
}

Or generic accessors? I do not think it's a friendly feature, I do not like it, for discussion only.

public TGetter Value
{
    get<TGetter> where TGetter : unmanaged
    {
        // todo
    }
    set<TSetter> where TSetter : struct => // todo
}

get accessors only:

public TGetter Value
{
    get<TGetter> where TGetter : unmanaged
    {
        // todo
    }
}

·Or·
public TGetter Value where TGetter : unmanaged => // todo

[bernd5]

Why not making your struct generic - something like:

using System;

Union32<int> union = new() { Value = 42 };
Console.WriteLine(union.Value);
var other = union.AsSomethingElse<TwoShorts>();
Console.WriteLine(other.Value.Part1);
Console.WriteLine(other.Value.Part2);

ref var refReinterpret = ref union.AsSomethingElseRef<int, TwoShorts>();
refReinterpret.ValueRef.Part1++;
Console.WriteLine(union.Value);


public struct Union32<T> where T : unmanaged
{
    private unsafe fixed byte _buffer[32];

    public ref T ValueRef 
    {
        get
        {
            unsafe
            {
                fixed (void* p = _buffer)
                    return ref System.Runtime.CompilerServices.Unsafe.AsRef<T>(p);
            }
        }
    }

    public T Value
    {
        get => ValueRef;
        set => ValueRef = value;
    }

    public Union32<X> AsSomethingElse<X>() where X : unmanaged
    {
        return this.AsSomethingElseRef<T, X>();
    }
}

public static class Union32Ext
{
    public static ref Union32<To> AsSomethingElseRef<From, To>(
        this ref Union32<From> me)
        where To : unmanaged
        where From : unmanaged
    {
        return ref System.Runtime.CompilerServices.Unsafe.As<Union32<From>, Union32<To>>(ref me);
    }
}

struct TwoShorts
{
    public short Part1;
    public short Part2;
}

[differentrain]

In terms of conciseness, I think the generic properties requires less and conciser code, both for implementation and invoking.

In terms of semantic definition, an union type provides various representations for same pointer (memory block), so union should not have type parameters. Accessing the same position in memory from properties is more rigorous.
By the way, this is why I do not like generic accessors, as I mentioned above. It is not "semantic".