[Propousal] ? mark generic parameter type / Reflection for all

[redradist]

When I have object type variable and want to get concrete type now you need to do some thing like this:

public class ObservableCollection<T> : ...
{
    ...
    public event NotifyCollectionChangedEventHandler CollectionChanged;
    ...
}

and I want to subscribe on CollectionChanged I need today to do something like this:

 object oldValue = ...; // It is set outside
 Type? oldValueType = oldValue?.GetType();
 if (oldValueType.GetGenericTypeDefinition() == typeof(ObservableCollection<>))
 {
      EventInfo collectionChangedEvent = oldValueType.GetEvent("CollectionChanged");
      MethodInfo removeHandler = collectionChangedEvent.GetRemoveMethod();
      object[] addHandlerArgs = {dynamicGrid.collectionChangedCallback};
      removeHandler.Invoke(newValue, addHandlerArgs);
  }

Proposal is to simplify it a little bit by adding Generic Parameter Type inference:

object oldValue = ...; // It is set outside
ObservableCollection<?> collection = oldValue as ObservableCollection<?>;
if (collection != null)
{
     collection.CollectionChanged += dynamicGrid.collectionChangedCallback;
}

it also could be simplified like this:

 object oldValue = ...; // It is set outside
 if (oldValue is ObservableCollection<?> collection)
 {
      collection.CollectionChanged += dynamicGrid.collectionChangedCallback;
 }

Also imagine more complex example:

    public struct ObservableCollectionChanged<T>
    {
      public T OldValue { get; set; }
      public T NewValue { get; set; }
      public int Index { get; set; }
    }

    public class ObservableCollection<T> where T : ISocketData 
    {
      public event EventHandler<ObservableCollectionChanged<T>> CollectionChanged;
      public int Index { get; set; } = 0;
      public T Item {
        get
        {
            return _list[Index];
        }
        set
        {
            _list[Index] = value;
        }
      }

      private List<T> _list;
    }

    interface ISocketData
    {
      void send();
    }
 
    class SocketData : ISocketData {
      public void send()
      {
        // some implementation
      }
    }

    static void Main(string[] args)
    {
      object cl = new ObservableCollection<SocketData>();
      if  (cl is ObservableCollection<?> collection) {
        int index = collection.Index; // Ok
        int item = collection.Item; // Compilation error, cannot take Item of unknown type and convert it to int
        var item = collection.Item; // Good, because it is taken as generic parameter type. Compiler will deduce item type as ISocketData
        // or you can do like this
        ISocketData item = collection.Item; // Good, because it is taken as generic parameter type. Compiler will deduce item type as ISocketData
        SomeCalculation(item); // Also good because generic item type do not have constraints as well as SomeCalculation method
        SendOverNetwork(item); // Compilation error, item do not satisfy ISocketData constraint
      }
    }

[HaloFour]

ObservableCollection<T> implements the non-generic INotifyCollectionChanged interface which exposes the CollectionChanged event:

object oldValue = ...;
if (oldValue is INotifyCollectionChanged collection)
{
    collection.CollectionChanged += dynamicGrid.collectionChangedCallback;
}

[redradist]

@HaloFour

ObservableCollection<T> implements the non-generic INotifyCollectionChanged interface which exposes the CollectionChanged event:

object oldValue = ...;
if (oldValue is INotifyCollectionChanged collection)
{
    collection.CollectionChanged += dynamicGrid.collectionChangedCallback;
}

Again you !!
Seems like you follow me ))

Do not be such straight forward even if it is possible for interface, imagine the situation where is no interface or interface is generic ? What to do in this case ?

[HaloFour]

@redradist

Seems like you follow me ))

I probably comment on most proposals on this repo. Call it boredom. 😁

Do not be such straight forward even if it is possible for interface, imagine the situation where is no interface or interface is generic ? What to do in this case ?

I'd say it depends on the use case. But faking some kind of generic subclass and emitting reflection-based code seems like a very inefficient and fragile way to accomplish any task. This seems relatively niche because it could only apply to generic classes where you don't know the generic type argument and you need to call a method that does not require you to know the generic type argument. Let's complicate the use case with the following:

public struct ObservableCollectionChanged<T> {
    public T OldValue { get; set; }
    public T NewValue { get; set; }
    public int Index { get; set; }
}

public class ObservableCollection<T> {
    public event EventHandler<ObservableCollectionChanged<T>> CollectionChanged;
}

Even if the compiler would let you reference the type as ObservableCollection<?>, what could you possibly pass to CollectionChanged? How would the compiler offer any compile-time validation?

[HaloFour]

I will note that I do like Java wildcards and variance, which do work with the ? symbol as suggested:

Object val = ...;
if (val instanceof List) {
    List<?> list = (List<?>) val;
    int size = list.size();
}

This is easier in Java because generics don't exist at runtime and List<String>, List<Integer>, List<?> and List are all the same type. In .NET they are separate distinct types. If C# were to explore this I'd like to see it handled by the CLR where you can establish variance wildcards on generic type parameters which dictate which methods you are allowed to invoke safely.

[redradist]

@HaloFour

@redradist

Seems like you follow me ))

I probably comment on most proposals on this repo. Call it boredom. 😁

Do not be such straight forward even if it is possible for interface, imagine the situation where is no interface or interface is generic ? What to do in this case ?

I'd say it depends on the use case. But faking some kind of generic subclass and emitting reflection-based code seems like a very inefficient and fragile way to accomplish any task. This seems relatively niche because it could only apply to generic classes where you don't know the generic type argument and you need to call a method that does not require you to know the generic type argument. Let's complicate the use case with the following:

public struct ObservableCollectionChanged<T> {
    public T OldValue { get; set; }
    public T NewValue { get; set; }
    public int Index { get; set; }
}

public class ObservableCollection<T> {
    public event EventHandler<ObservableCollectionChanged<T>> CollectionChanged;
}

Even if the compiler would let you reference the type as ObservableCollection<?>, what could you possibly pass to CollectionChanged? How would the compiler offer any compile-time validation?

@HaloFour Seems like you are right ... Using types that depend on generic parameter type is useless ...

But lets think a little bit ...

What if we allow use methods, events, properties that do not depend on generic parameter type in user context ?

I will show an example:

    public struct ObservableCollectionChanged<T>
    {
        public T OldValue { get; set; }
        public T NewValue { get; set; }
        public int Index { get; set; }
    }

    public class ObservableCollection<T>
    {
        public event EventHandler<ObservableCollectionChanged<T>> CollectionChanged;
        public int Index { get; set; } = 0;
        public T Item {
            get
            {
                return _list[Index];
            }
            set
            {
                _list[Index] = value;
            }
        }

        private List<T> _list;
    }

    interface ISocketData
    {
      void send();
    }

    class Program
    {
        void SomeCalculation<T>(T item)
        {
          Console.WriteLine(item);
        }

        void SendOverNetwork<T>(T item) where T: ISocketData
        {
          item.send();
        }

        static void Main(string[] args)
        {
            object cl = new ObservableCollection<string>();
            if  (cl is ObservableCollection<$> collection) {
              int index = collection.Index; // Ok
              int item = collection.Item; // Compilation error, cannot take Item of unknown type and convert it to int
              $ item = collection.Item; // Good, because it is taken as generic parameter type. $ here is any generic parameter
              SomeCalculation(item); // Also good because generic item type do not have constraints as well as SomeCalculation method
              SendOverNetwork(item); // Compilation error, item do not satisfy ISocketData constraint
            }
        }
    }

As you have mentioned in my example I have changed ? -> $ as generic parameter type
As you can see from my example it would be possible to have some kind generic programing without introducing a lot of reflection ;)

[theunrepentantgeek]

This is now looking very much like something that would be solved with Shapes (#164) or Roles (#1711).

[HaloFour]

@redradist

$ item = collection.Item; // Good, because it is taken as generic parameter type. $ here is any generic parameter

How exactly do you propose this work? $ doesn't exist as a type, nor is there anything that remotely works like that at the IL level. What could you even do with item? You can't safely pass that to anything else. At best you can use Object but that would have very different semantics compared to what the real type would be.

Not even Java permits this, and it has fairly loose wildcard bounds given that generics don't actually exist at runtime.

As you can see from my example it would be possible to have some kind generic programing without introducing a lot of reflection ;)

There's still a lot of reflection, you're just having the compiler emit it. You can't represent any of this using proper IL.

[redradist]

@redradist

$ item = collection.Item; // Good, because it is taken as generic parameter type. $ here is any generic parameter

How exactly do you propose this work? $ doesn't exist as a type, nor is there anything that remotely works like that at the IL level. What could you even do with item? You can't safely pass that to anything else. At best you can use Object but that would have very different semantics compared to what the real type would be.

@HaloFour In this example I can do very little with item, but if this item has constraint I can apply to it some operations:

$ item = collection.Item;
item.send(); // Could work if Item has type T that has constraint ISocketData

And $ mean meant in my example type inference, actually we can use existed keyword var as well:

var item = collection.Item;
item.send(); // Could work if Item has type T that has constraint ISocketData

And the final example would be:

        interface ISocketData
        {
           void send();
         }
 
         class SocketData : ISocketData {
           public void send()
           {
             // some implementation
            }
         }

        static void Main(string[] args)
        {
            object cl = new ObservableCollection<SocketData>();
            if  (cl is ObservableCollection<?> collection) {
              int index = collection.Index; // Ok
              int item = collection.Item; // Compilation error, cannot take Item of unknown type and convert it to int
              var item = collection.Item; // Good, because it is taken as generic parameter type. Compiler will deduce item type as ISocketData
              // or you can do like this
              ISocketData item = collection.Item; // Good, because it is taken as generic parameter type. Compiler will deduce item type as ISocketData
              SomeCalculation(item); // Also good because generic item type do not have constraints as well as SomeCalculation method
              SendOverNetwork(item); // Compilation error, item do not satisfy ISocketData constraint
            }
        }

Not even Java permits this, and it has fairly loose wildcard bounds given that generics don't actually exist at runtime.

As you can see from my example it would be possible to have some kind generic programing without introducing a lot of reflection ;)

There's still a lot of reflection, you're just having the compiler emit it. You can't represent any of this using proper IL.

But it is better from user point of view ... =)
Yes, I want less a reflection because it makes code less readable ... ( But in some cases without a reflection it is not possible, I agree ...

But what is wrong if compiler will emit all this reflection stuff ?
It will make code more readable as in its time async await did ;)

[theunrepentantgeek]

Reflection code is very slow - so there's benefit in requiring developers to be explicit when using it, so they know that they're paying that performance cost.

Hiding reflection behind a language feature like this makes it extremely likely that some will use it without realizing the cost.

[redradist]

Reflection code is very slow - so there's benefit in requiring developers to be explicit when using it, so they know that they're paying that performance cost.

Hiding reflection behind a language feature like this makes it extremely likely that some will use it without realizing the cost.

@theunrepentantgeek
It is not a problem ...
It is possible to add special kind of flag that will enable this feature if user explicitly wanted it, like with nullable reference types ;)

Also garbage collection could be expensive !! But who care ? If developer does not face with performance issue than he wants such performance ...
Also I remember a good phrase: "Do not optimize your code until it's nessesery to you !!"

[theunrepentantgeek]

Nullable reference types is a special case where the LDM decided it was worth introducing a feature flag because the expected benefit is huge.

They've been very clear in the past that they do not want to create different dialects of the C# language because it shards the community, creating different incompatible factions.

One factor that's often overlooked is that every feature flag doubles the number of dialects, it's not incremental. If you had just five worthwhile features governed by feature flags, that's 32 dialects of the language ...

[redradist]

@theunrepentantgeek

Nullable reference types is a special case where the LDM decided it was worth introducing a feature flag because the expected benefit is huge.

They've been very clear in the past that they do not want to create different dialects of the C# language because it shards the community, creating different incompatible factions.

One factor that's often overlooked is that every feature flag doubles the number of dialects, it's not incremental. If you had just five worthwhile features governed by feature flags, that's 32 dialects of the language ...

Okay, I agree, then please add this feature using reflection under the hood !! What is the problem ?

@theunrepentantgeek

Reflection code is very slow - so there's benefit in requiring developers to be explicit when using it, so they know that they're paying that performance cost.

Hiding reflection behind a language feature like this makes it extremely likely that some will use it without realizing the cost.

Okay, okay, I see what's the problem ...
No, I DO NOT !! ;)

You think that reflection should be obvious, because of performance, but what about async await, they also adding pressure on code size and on run-time and what ?

Adding this feature by compiler simplified a lot of boilerplate code, on the other hand issue with performance you can leave to performance analysis tool or by adding another flags that shows warning on performance trade-offs by generated code ...

Anyway, because it is generated code you can even optimize it a little bit, when user could wrote such code that would not be possible to optimize !!

[CyrusNajmabadi]

Adding this feature by compiler simplified a lot of boilerplate code,

THere are other features that are being planned which may subsume this entirely. So it wouldn't make sense to do this feature if it's just going to be immediately obsoleted by other mechanisms.

[redradist]

@CyrusNajmabadi

Adding this feature by compiler simplified a lot of boilerplate code,

THere are other features that are being planned which may subsume this entirely. So it wouldn't make sense to do this feature if it's just going to be immediately obsoleted by other mechanisms.

What are the other mechanisms ?
Also it should be readable as general code ... but it is only my opinion ;)

[redradist]

@CyrusNajmabadi @HaloFour @theunrepentantgeek
Recently I have faced exactly with need of this feature:

        public static async ValueTask<object?> InvokeValueAsync(this MethodInfo @this, object obj, params object[] parameters)
        {
            var task = (ValueTask<?>)@this.Invoke(obj, parameters);
            await task!.ConfigureAwait(false);
            var resultProperty = task.GetType().GetProperty("Result");
            return resultProperty!.GetValue(task);
        }

And it is not possible ... (

One solution is:

        public static async ValueTask<object?> InvokeValueAsync(this MethodInfo @this, object obj, params object[] parameters)
        {
            dynamic task = @this.Invoke(obj, parameters);
            await task!.ConfigureAwait(false);
            var resultProperty = task.GetType().GetProperty("Result");
            return resultProperty!.GetValue(task);
        }

But it is not possible for iOS platform with keyword dynamic ... (

I was lucky because for this particular struct I can do something like this:

        public static async ValueTask<object?> InvokeValueAsync(this MethodInfo @this, object obj, params object[] parameters)
        {
            var task = @this.Invoke(obj, parameters);
            var newTask = (Task?)task!.InvokeMethod("AsTask");
            await newTask!.ConfigureAwait(false);
            var resultProperty = newTask.GetType().GetProperty("Result");
            return resultProperty!.GetValue(newTask);
        }

But I was lucky because imagine how may cases where no simple conversion from generic struct to something to call method !!

[CyrusNajmabadi]

The choice here is that you will have to call to the actual instantiations you get. There is no other way given the limitations your have stated.

I don't know what you're going for here :-). If your runtime is going to have these limitations, there's nothing we can do about that. Any solution we'd make would have the same limitations. I.e. we'd have to call into reflection. So it would still not work on your platform.

If dynamic introspection is blocked we cannot dynamically introspect your generic types. You can't have it both ways.

[CyrusNajmabadi]

I can use only reflection, but without interface even reflection is not useful ... (

If you can use reflection, what is the problem?

[redradist]

I can use only reflection, but without interface even reflection is not useful ... (

If you can use reflection, what is the problem?

@CyrusNajmabadi How to use reflection for such example:

struct SomeStruct<TItem>
{
    public bool IsAvailable => Item != null;
    public TItem? Item { get; set; }
}

object someStruct = new SomeStruct<int>();
...
// Some code that use reflection and I as consumer do not know generic type int ???
var particularStruct = (SomeStruct<?How to cast?>) someStruct;

Do not forget that SomeStruct<TItem> is not my, it is not in my code ...

[HaloFour]

@redradist

You use reflection to negotiate the surface of the type and call its members directly. It has nothing to do with casting.

var type = someStruct.GetType();
var property = type.GetProperty("IsAvailable");
var isAvailable = (bool) property.GetValue(someStruct);

[redradist]

@redradist

You use reflection to negotiate the surface of the type and call its members directly. It has nothing to do with casting.

var type = someStruct.GetType();
var property = type.GetProperty("IsAvailable");
var isAvailable = (bool) property.GetValue(someStruct);

@HaloFour Uh, it is bad example from my side :)
Let me think about some tricky example ...

[redradist]

@CyrusNajmabadi @HaloFour With such feature would be possible to call extension methods on type with ?

[redradist]

@MadsTorgersen @CyrusNajmabadi @HaloFour

I cannot find a good example for this feature that could not be done with reflection ...

But it does not mean that this feature is meaningless, because if such feature would exist then it is like reflection api for humans where you can to work with types even that you do not have all information for this type and use this only needed properties of this type

Lets consider pros and cons of this feature:

Pros:

1. It will improve quality for reflection code, because it will look like general code, but with some missed information

2. It will allow for better interop with Java, it will allow easier to convert Java library with List<?> syntax to C#, but C# will know at run-time type of generic parameter that will make C# solution more powerful

3. It will improve readability of C# code

Cons:

1. It will add extra instruction to IL code and runtime

[HaloFour]

Java generics work very differently because they don't actually exist at runtime at all. That lets you play fast and loose, but also makes the language features much more complicated. Wildcards and bounds are one of the most complicated aspects of the Java language and can be very easy to get wrong (and infuriating to fix without resorting to unchecked conversions).

Adding wildcards and bounds to the .NET runtime and to every .NET language would be a massive undertaking. Considering that there are multiple ways to workaround this issue it seems to me that there'd be very little reason to do so.

[redradist]

Java generics work very differently because they don't actually exist at runtime at all. That lets you play fast and loose, but also makes the language features much more complicated. Wildcards and bounds are one of the most complicated aspects of the Java language and can be very easy to get wrong (and infuriating to fix without resorting to unchecked conversions).

Adding wildcards and bounds to the .NET runtime and to every .NET language would be a massive undertaking. Considering that there are multiple ways to workaround this issue it seems to me that there'd be very little reason to do so.

@HaloFour Again, I understand how generics in Java works, as for me in C# generics works much better because at run-time I can get real type of collection

But this feature will make code more readable:

var particularStruct = (SomeStruct<?>) someStruct;
var isAvailable = particularStruct.IsAvailable;

instead of:

var type = someStruct.GetType();
var property = type.GetProperty("IsAvailable");
var isAvailable = (bool) property.GetValue(someStruct);

Code with <?> could be compiled to:

        IL_0000: ldloca.s 0
        IL_0002: initobj valuetype SomeStruct`1<int32>
        IL_0008: ldloc.0
        IL_0009: box valuetype SomeStruct`1<int32>
        IL_000e: unbox.any valuetype SomeStruct`1<?>
        IL_0013: pop
        IL_0014: ret

During casting to SomeStruct``1<?> .NET Runtime will figure out real type of object SomeStruct``1<int32> and cast to it

As you can see this feature is only compiler technology, runtime generics are the same

? just says that during compilation I do not know concrete generic parameter, but please figure out it and cast to real type

What happens if user will try to access Item ?

var particularStruct = (SomeStruct<?>) someStruct;
var isAvailable = particularStruct.IsAvailable;                 // No problems
var item = particularStruct.Item;                                   // Error, cannot deduce type of Item
var item = (object) particularStruct.Item;                       // No problems
particularStruct.Item.CallMethod();                               // Error, call method on unknown type

As you can see this feature simplifies work with generic collection with unknown generic parameter

[HaloFour]

@redradist

Code with <?> could be compiled to:

No, it couldn't, not without massive changes to how generics work in the runtime. IMO making reflection code slightly easier to read in order to work around poorly designed APIs seems far from a justifiable reason to invest so much into gutting and reworking generics.

[redradist]

@redradist

Code with <?> could be compiled to:

No, it couldn't, not without massive changes to how generics work in the runtime. IMO making reflection code slightly easier to read in order to work around poorly designed APIs seems far from a justifiable reason to invest so much into gutting and reworking generics.

@HaloFour Why do you need to rework whole generic runtime behavior ? I consider this feature only as one extra instruction to IL code, that's all ...

As for me it seems like feasible, but seems like you have some issues with internal structure of generic, how they saved in runtime, am I right ?

[CyrusNajmabadi]

I consider this feature only as one extra instruction to IL code, that's all ...

You can't really state this about ' an extra instruction'. i.e. i coudl have a single isntruction which was 'solve the traveling salesperson problem' :) And that wouldn't make it easy or simple to provide. You have to actually explain and justify the complexity that wuold have to go into adding support for that instruction. In this case, it seems substantial (but i'm open to an argument that it would not be).

[HaloFour]

@redradist

I consider this feature only as one extra instruction to IL code, that's all ...

An instruction that casts an instance to a type that doesn't exist and allows invoking members with partial signatures would most certainly not easy to implement. If you think it is you can feel free to go to the runtime repo and tell them how they would do it.

[redradist]

I consider this feature only as one extra instruction to IL code, that's all ...

You can't really state this about ' an extra instruction'. i.e. i coudl have a single isntruction which was 'solve the traveling salesperson problem' :) And that wouldn't make it easy or simple to provide. You have to actually explain and justify the complexity that wuold have to go into adding support for that instruction. In this case, it seems substantial (but i'm open to an argument that it would not be).

@CyrusNajmabadi Any feature is adding some complexity, but this feature as for me deserve to work with complexity, because it will bring "Reflection for all" and make other people wirting frameworks, libraries, improve learning C# easier and also improve quality of reflection code

[HaloFour]

@redradist

Any feature is adding some complexity, but this feature as for me deserve to work with complexity,

It's a matter of ROI. This feature involves a lot of complexity, especially given how much work would be required in the runtime to make it possible even before considering what language syntax might look like. If the benefit is limited to making it slightly easier to write code that you can write today using reflection or dynamic then it's certainly not worth that effort. This is a niche situation that is easily solved using language and runtime features that have been there since the beginning.

Massive amounts of work for very little reward in very niche scenarios, it's not worth it.