Why does the compiler consider the return type Func <dynamic, int> to be strongly typed?

Question

Why the next compiler? It seems that the compiler has enough information to know that an assignment attempt is not allowed, since the return type Func <> is not dynamic.

Func<dynamic, int> parseLength = whatever => whatever.Length; dynamic dynamicString = "String with a length"; DateTime wrongType = parseLength(dynamicString); 

Answer 1

It seems that the compiler has enough information to know that an assignment attempt is not valid, since the return type Func<> not dynamic.

Caution: Of course, I no longer speak for the C # development team; this is my opinion on language design.

So what are you saying here: "I turned off the security system. Why doesn't the security system turn off when I do something dangerous and stop me?" Well, if this is what you wanted, perhaps you should not disable this security system in the first place.

However, you are right; a “disconnected type” security system can indeed continue to work here and discover that you are doing something dangerous. In fact, there are many situations where a smart enough compiler can make a type conclusion about dynamic subexpression. You have found one of them. Implementing the necessary analysis is a function request.

So, the urgent question: what function of C # would you like to reduce in order to give the development team a budget for designing, specifying, implementing, testing, debugging, sending and maintaining forever a function that statically detects an error in a program where the developer explicitly asks to disable static checking ? Keep in mind that cost includes ensuring that no future language feature ever prevents the compiler from making this conclusion; some of these costs are taxes that are paid in the future by the development team.

There are few scenarios where an expression containing dynamic is statically parsed; for example, there are some problems with overload resolution associated with static methods with dynamic arguments, where the compiler can and can find out that no matter what is provided at run time, overload resolution will fail. But, in addition to those few cases, the language development team has historically estimated that it’s just not very good to spend a limited budget on scripts like the ones you defined.

Answer 2

Since the input is dynamic, the compiler cannot even determine if the result of your function is int. It will try to pass the result to int during the execution of the function and fail if it is not possible. Now, if you ask why you are even allowed to create such code if the restriction of the static type cannot be enforced, remember that dynamics is not so much a type as a warning flag for "your usual static type rules", apply here "

Check out the concept of "dynamic infection" for a deeper understanding.

Answer 3

A type is a static type, but an object of type dynamic bypasses static type checking.

If any part of your type is dynamic, the compiler should consider everything as dynamic. So:

 Func<dynamic, int> parseLength = <some func> // is dynamic and type cannot be evaluated until runtime. 

So, the compiler resolves this code:

 DateTime wrongType = parseLength 

This compiles and, as you expect, will cause a runtime error.

Dynamic typing is useful in certain circumstances. My personal experience with this value is access to unmanaged code in COM components.

Basically, he tells the compiler: “Believe me, this will work. =)” Or: “These are not the droids you are looking for”