0

I am new to C# and was trying to write an SNTP server on the weekend. During the course of this development I ended up with exactly the same question as this one: How to use generics to pass argument to a non-generic method?

The question, repeated here is: "How to use generics to pass argument to a non-generic method?" The crucial answer to this question was that the non-generic method in question didn't have an overload which accepted an Object.

Now the question I have is a follow on question: why is Generics implemented this way? Or to rephrase, why are constraints required at all?

My understanding so far is that generics help to preserve compile time type safety which means that the compiler knows what types are being dealt with at compile time.

Why wasn't C# (or perhaps this question should pertain to the CLR) implemented such that the compiler can accept the fact that a generic class/method is being created in which an argument can be provided which may not be acceptable in all cases. Then, when the generic class/method get's invoked, the compiler can see the issue and complain at that time.

Is this a technical limitation?

It just seems like a real pity that a generic method cannot be created to wrap a non generic method with multiple overloads. Unless I opt to defer type checking to run time which is the solution to the aforementioned question, I would have to wrap this overloaded method with a suite of methods, one for each signature, even though the code within it will look identical. This would have been an ideal place to leverage a generic method.

Gregory Kuhn
  • 1,627
  • 2
  • 22
  • 34
  • It wouldn't be generics then, it would be dynamic typing. And you'd get a runtime error. Precisely what you *don't* want to happen. You want the *compiler* to tell you that you passed the wrong type so you can fix it. BTW you *can* use `dynamic` as the generic type, losing all the type checking benefits – Panagiotis Kanavos Oct 31 '17 at 14:37
  • It sounds like you're describing `dynamic`. `dynamic` variables are type checked just like generics, but at runtime, not compile time. There are reasons why you might make that choice. But compile time safety is a rather useful tool. As with all things, you make your choice based on the tradeoffs involved. – Robert Harvey Oct 31 '17 at 14:38
  • No, my question relates to why the compiler cannot statically ensure type compatibility when the Generic in question is invoked, as opposed to ensuring this with constraints (or in my case, a "computer says no" scenario). – Gregory Kuhn Oct 31 '17 at 14:41
  • That's what `dynamic` does. It checks the type when the method is invoked, and throws an exception if it doesn't. – Robert Harvey Oct 31 '17 at 14:42
  • For generics, the answer is often "will this feature actually work considering that the generic type `T` might be both a value and a reference type, and we must know in advance to generate/invoke the correct generic implementation"? The compiler is reluctant to insert fixup code to make such cases work, because the C# designers prefer a "what you see is what you get" approach to such things. – Jeroen Mostert Oct 31 '17 at 14:44
  • Possible duplicate of [How are C# Generics implemented?](https://stackoverflow.com/questions/11436802/how-are-c-sharp-generics-implemented) – StayOnTarget Dec 04 '18 at 16:19

1 Answers1

2

The person who can best explain this is Eric Lippert, and he did, in What’s the difference, part one: Generics are not templates:

We do the overload resolution once and bake in the result. We do not change it at runtime when someone, possibly in an entirely different assembly, uses string as a type argument to the method. The IL we’ve generated for the generic type already has the method its going to call picked out. The jitter does not say “well, I happen to know that if we asked the C# compiler to execute right now with this additional information then it would have picked a different overload. Let me rewrite the generated code to ignore the code that the C# compiler originally generated...” The jitter knows nothing about the rules of C#.

[...]

Now, if you do want overload resolution to be re-executed at runtime based on the runtime types of the arguments, we can do that for you; that’s what the new “dynamic” feature does in C# 4.0. Just replace “object” with “dynamic” and when you make a call involving that object, we’ll run the overload resolution algorithm at runtime and dynamically spit code that calls the method that the compiler would have picked, had it known all the runtime types at compile time.

So why not: because the runtime wouldn't know how to re-generate the required code.

And something about a design philosophy that your code should fail as early as possible, preferably during compile time, but I can't find that quote right now.

Community
  • 1
  • 1
CodeCaster
  • 147,647
  • 23
  • 218
  • 272
  • Ok, it's making more sense. Just to clarify my understanding, let's say in the case where I am using generic_method and generic_method, how come the compiler can't bake in two versions of generic_method, where I have invoked them in the code? Or am I thinking too much along the lines of templates? – Gregory Kuhn Oct 31 '17 at 14:58
  • Because the compiler resolves the best overload at compile-time. The runtime just runs the code, it's not going to second-guess the compiler and choose another overload at runtime. – CodeCaster Oct 31 '17 at 15:08