Dynamic Generics

[MiddleTommy]

I often wish generics in c# would work like this.

var mytype = MyObject.GetType();
var list = new List<mytype>();

Often you can't use generics because you don't know the type at compile time. Who would like to have all the reflection code to make this work, generated for you at compile time?

[tacosontitan]

If you don't like writing the reflection, then there are some options:

• Refactor so the type is known at compile time.
• Create an extension method.
• Create a source generator.

I can't say there has ever been a situation that I had control over in which I couldn't know the type at compile time. Consequently, since this is something you encounter often, can you provide a use case in which the type couldn't possibly be known at compile time?

[MiddleTommy]

@tacosontitan
All I can say is your arguments are good if you get paid by the hour to write code.

[tacosontitan]

I am 100% self-taught. I had no mentors, just documentation and blogs.

I'm 100% self-taught myself, but that doesn't mean that there weren't others around me to tell me "that's stupid, try something else" or "look into this". If you've worked in a professional capacity for any length of time and had no mentors, then your peers failed you, or you failed yourself by not letting them mentor you.

[tacosontitan]

All I can say is your arguments are good if you get paid by the hour to write code.

I'm salary, but that doesn't mean I have to write slam code all the time. I slam in emergencies, but those are exceptions, not the norm. I'm not afraid to tell my superiors when something isn't possible to do in a maintainable way in the timeline they want, and they advise me from there. Deadlines are not a reason to write bad code.

Only you can prevent dumpster fires.

[MiddleTommy]

Look @tacosontitan. I am a solo self-taught developer and have never talked to anyone in person ever in my life and only a couple times online about coding. It has always just been me and no-one around me cares. So please tone down the best practices hocus pocus. I just want to get things working as quick as possible and refactor later if needed. You think my idea is bad. thanks, move on.

[tacosontitan]

I'm not on "best practices hocus pocus" because I think best practices can constrain a developer too much; they're guidelines, not laws. I'm simply trying to get you to give us a concrete example (with code) that would support this so that we can better understand your idea. If I've offended you, then I apologize, but I'm not attacking you, I'm simply being blunt.

[TahirAhmadov]

I can understand what is requested, and I can even imagine situations where this would be needed. But:

1. These situations are very uncommon from the perspective of the overall ecosystem;
2. The proposed syntax is very confusing - language needs to interpret whether the provided identifier is a type or a variable holding a Type, and if you consider that it could be a property, it becomes difficult to read - is ElementType in List<ElementType> a type or a property named ElementType?
3. In addition to 2 above - do we also support expression? Then it can become really unwieldy, like List<someVar.Prop.Foo()>
4. The readily available API call is not that complicated to warrant a language improvement.

[HaloFour]

We should be improving those dynamic features so when needed it is less of a pain to use c#. Yes, dynamic C# is needed.

Or, you could use one of many available dynamic languages that interops with the CLR. C# isn't trying to be every language, and it's not a goal to become a dynamic language.

[MiddleTommy]

@HaloFour Why would I want to include a dependency on another language and runtime just to process a few lines of code I could write in reflection? Yes, this is not a needed feature. It is a want, to solve a few situations. However, I feel it would be used more often if available. Right now we avoid these situations because they are painful. So, we write way more code to cover Type safety.

At my real job we process steel. We used to cut all plates out of standard width bar sizes (1 inch to 12 inches wide in 1/2 inch increments) because cutting plate manually by hand was time consuming. Plates would be sticking out or inset a little when welded into other steel shapes. We didn't like curves or shapes in plate and forced everything to be only rectangles. Then we got a CNC plasma plate cutter. We still use bar size widths but also cut plates to any size or shape with ease and speed. We can even cut bar sizes out of bigger plates. However, we had to spend $150K to get that machine.

I feel features like this one would be like getting that plasma plate cutting machine for C#. We use the types as often as we can but when that odd shape or situation comes around it would be no problem.

Generics are dynamic in their nature. Its time we make dynamic generics.

[HaloFour]

Why would I want to include a dependency on another language and runtime

Probably the same reason a toolbox generally contains more than one tool.

However, I feel it would be used more often if available.

Brittle and slow should not be encouraged. C# already offers runtime binding to simplify working with dynamic code via the DLR and dynamic.

Generics are dynamic in their nature.

Generics are definitely not dynamic in their nature.

[MiddleTommy]

@HaloFour I would agree consuming generic objects is not dynamic. However, when authoring generic classes you often need to think in dynamic ways.

[tacosontitan]

Im not a fan of "new from" as this is different than normal c# code and doesnt work for generic methods.

Your example is not leveraging generics...

public interface ISample { int Value { get; set; } }

...
public bool Foo<TIn>(TIn input)
    where TIn : ISample, new()
{
    if (input.Value % 3 == 0)
        return true;

    TIn newSample = new();
    newSample.Value = input.Value * 32;

    return Bar(newSample);
}

public bool Bar<TIn>(TIn input)
    where TIn : ISample =>
    input.Value % 5 == 0;

While redundant, the new from would certainly work with generic methods:

public bool Foo<TIn>(TIn input)
    where TIn : ISample
{
    if (input.Value % 3 == 0)
        return true;

    var collection = new from(List<>, typeof(TIn));
    for (int i = 0; i < input.Value; i++)
    {
        TIn newSample = new();
        newSample.Value = input.Value * i + 32;
        collection.Add(newSample);
    }

    return collection.All(Bar);
}

However, there are tons of questions and downsides to this approach that make me want to stay away from it. I'd much rather just leverage generics the way they were intended to be used.

[theunrepentantgeek]

The infrastructure to "recover" from having a non-generic value already exists with dynamic - here's an example that shows how you can go from something held in a variable of type object to a List<T> with the correct value for T:

    public void M() 
    {
        var item = 9;
        object obj = item;
        dynamic dyn = item;
        
        var listA = CreateList(item);
        Console.WriteLine(listA.GetType().ToString());
        
        var listB = CreateList(obj);
        Console.WriteLine(listB.GetType().ToString());
        
        var listC = CreateList(dyn);
        Console.WriteLine(listC.GetType().ToString());
    }
    
    private IEnumerable<T> CreateList<T>(T item) 
    {
        return new List<T>{ item };
    }

SharpLab

HOWEVER, the problem is that you can't do very much with the list once you have it. Sure, it's a List<T>, but you can't treat it as a List<T>, you have to treat it as a non-generic type, say IEnumerable, which kinda defeats the point.

I've needed code just like that in the original post. And the fix was to propagate the generic types out from that point, so that you don't end up with MyObject of type Object, you end up with something of a definite type.

Often you can't use generics because you don't know the type at compile time.

Generic library code that I write never knows the type at compile type. That's literally why I write generic code, so that it works even though I don't know the actual type that will be used.

[iam3yal]

I think that your example in the OP doesn't really represent the problem, in my experience the problem many times is with library authors that are exposing only the generic version of a type or a method and it may be totally appropriate but then consumers needs to deal with it in their edge cases and it's certainly shouldn't be a common practice but if it is, you either trying to use the wrong tool for the job or picked the wrong language for you to begin with so I really don't think the language needs to change because of that and I don't think something like this would ever make it into the language not only because it shouldn't be common but the reliance on reflection is detestable; however, you can always write utility or extension methods to ease your pain.

I'd love to have generic specialization, (a lot) more generic type inference, C++ concepts like feature for generics but dynamic? maybe in some other circumstances.

Referencing your old issue #2802 from 2019.