dynamic method parameter makes non-awaitable method awaitable

[micklaw]

Hey folks,

My collegue and I were in around some oddly structured legacy code today and noticed something we were both surprised by that wasn't picked up by the compiler.

When passing a dynamic parameter in to a method, even if the method is not awaitable, if you call await on it, the value is returned without any compiler warning. The example class below compiles without issue.

public class Test
{
    private IEnumerable<dynamic> NonAwaitableMethod(string input)
    {
        yield return input;
    }

    public async Task<IEnumerable<dynamic>> BorkedDynamicAsync(string input)
    {
        dynamic value = "String";
        var awaitedIEnumerableStringList = await NonAwaitableMethod(value);

        return awaitedIEnumerableStringList;
    }
}

Expected Result:

'IEnumerable' does not contain a definition for 'GetAwaiter' and no accessible extension method 'GetAwaiter' accepting a first argument of type 'IEnumerable' could be found (are you missing a using directive or an assembly reference?)

Actual Result:

No errors

Debugging

If you run this example with the following Program.cs main. the program completes successfully.

static async Task Main(string[] args)
{
    var testService = new Test();

    Console.WriteLine("Hello Borked World! - " + testService.BorkedDynamicAsync("Chaos"));
    Console.ReadKey();
}

Output: Hello Borked World! - System.Threading.Tasks.Task1[System.Collections.Generic.IEnumerable1[System.Object]]

When awaited we rightly get the exception I would expect to see.

static async Task Main(string[] args)
{
    var testService = new Test();

    Console.WriteLine("Hello Borked World! - " + (await testService.BorkedDynamicAsync("Chaos")).First());
    Console.ReadKey();
}

Output: Microsoft.CSharp.RuntimeBinder.RuntimeBinderException: ''AwaitSyncTest.Test.d__0' does not contain a definition for 'GetAwaiter''

Feels odd, I'm nt sure there is a reason for this, but thought it best be reported.

Thanks

[HaloFour]

dynamic is viral like this. Because value is declared as dynamic everywhere you use value as a parameter the entire expression becomes dynamic and won't be evaluated until runtime.

[micklaw]

Hey @HaloFour

Interesting the entire expression is not evaluated until runtime as soon as dynamic becomes involved.

Would it be best placed to check the return type of the method in an analyzer to make this feedback early in the development loop. Though this example is clearly kind of crazy, we had an issue of somthing similar in a library making it though our CI/CD process as this did not flag up what clearly would have been an error at runime (yes, no tests were involved in this process :( ).

[logisticpeach]

This is really interesting. I can understand the semantics after analysing this (and also thanks to the helpful update from @HaloFour) but I can also see huge scope for unintentional problems.

I wonder if it would be helpful for the compiler to issue a level 4 warning when this kind of dynamic evaluation spans more than a single expression. Maybe @micklaw's suggestion of an analyzer would be more "light touch" and less likely to annoy regular users of the dynamic keyword.

[paulomorgado]

dynamic is used for late bound and it's a way to tell the compiler "I know that, at run-time, this will be there". Pretty much like the ! operator for nullable reference types.

If you want compile-time checks, don't use dynamic. I don't claim to have seen all the code in the world but, I've seem very few legitimate uses of dynamic and lots of abuses of it.

[micklaw]

@paulomorgado

Yeah, I absolutely get that perspective my issue is not with the technical details of why it is ignored, it is more that it is not obvious that using dynamic in this context with these side effects is not well known by the community IMO.

For instance, the code we have inherited has been poorly constructed, and there are two methods of similar names doing similar things, one is async, one is not. Though simply because their input is dynamic type safety is lost causing the wrong method to easily be selected without compile warnings.

I personally do not believe that it is common knowledge using the dynamic keyword causes the entire expression to be ignored until runtime, and feel it dangerous for us to make the assumption that all dotnet developers understand this too.

Edit: Also, I agree using dynamic = bad. Though in this case it is having no operation done on it, it is simply used to pass its value to a method.

[paulomorgado]

@micklaw,

Check here:

The dynamic type
Using type dynamic (C# Programming Guide)

If you feel something is missing or not clear on the docs, open an issue right there. Feel free to cc me.

[micklaw]

Thanks, and yes updating the docs could be a good shout here, though probably in honesty wouldn't have helped us in this case.

Finally, I'd argue that...

dynamic dynamic_ec = new ExampleClass();
dynamic_ec.exampleMethod1(10, 4);

...is a world away from.

public class Test
{
    public async Task<IEnumerable<string>> AsyncMethod(string input)
    {
        dynamic value = "String";
        var awaitedIEnumerableStringList = await SomeMethod(value);

        return awaitedIEnumerableStringList;
    }

    private IEnumerable<string> SomeMethod(string input)
    {
        yield return input;
    }
}

Happy to be proven that my knowledge of the dynamic keyword is less detailed than it should be though, and thats something I'll take on board.

[paulomorgado]

Any expression involving dynamic is dynamic. That is the part that might be better documented.

But I fail to understand where dynamic_ec.exampleMethod1(10, 4) is worlds apart from SomeMethod(value).GetAwaiter().

[CalinBunea]

Because then compiler has no way to know what the actual return type will be at runtime. It could be anything.

If i have collectionOfStrings.Select(str=>MakeACallAsync(str,someDynamicParam)) how the compiler cannot know the return type of method "MakeACallAsync"???

[CyrusNajmabadi]

MakeACallAsync is picked at runtime and may be a totally different method. That's the nature of dynamic dispatch.

[CalinBunea]

MakeACallAsync is picked at runtime and may be a totally different method. That's the nature of dynamic dispatch.

Can you please provide me such an example? I still don't understand how a piece of code could "change" at runtime... Basically I'm passing a "Func<Task < string >,dynamic>" and the compiler "cannot be sure" that the func that I'm passing would return a "Task< string >". In what context it cannot be sure about this?

[canton7]

Imagine there are multiple overloads of MakeACallAsync, which take a different parameter type and return different types. The overload which is called is based on the runtime type of that dynamic argument.

[svick]

@CalinBunea

I still don't understand how a piece of code could "change" at runtime

If it's code in another assembly, just compile against one version and then execute against another.

If it's code in the same assembly, then it would require IL rewriting after compilation, e.g. using something like Mono Cecil.

[micklaw]

I'm glad we agreed on the first point :)

On the latter point though, dynamic is just an input to the method 'SomeMethod', I get that whatever the dynamic parameter is doing we do not know until runtime. What we do know however at compile time is that the return type of 'SomeMethod' is never going to be awaitable, so why not flag that? There is obviously some low level technical reason I am missing here and that's fine, it just seems strange to me that something so immediately obvious to the eye can not be caught by the compiler or an Analyzer, or maybe it can and just needs written?

[Richiban]

@micklaw Unfortunately if any part of an expression is dynamic, even an input to a method call, overload resolution is pushed to runtime and therefore the C# compiler cannot 100% deduce the return type of the method you have called.

Therefore the whole expression has the type dynamic and the compiler must allow you to await it.

I hope that makes sense. I know that when dynamic first came out I struggled with similar issues.

[yaakov-h]

What we do know however at compile time is that the return type of 'SomeMethod' is never going to be awaitable, so why not flag that?

How does the compiler know that the runtime will resolve it to the particular method that you have in mind?

[micklaw]

How does the compiler know that the runtime will resolve it to the particular method that you have in mind?

It won't. My point is that dumping a whole expression to the runtime just as cause a single input property is a dynamic type feels harsh, thats all.

As I say, I'm happy to be wrong in my assumption that this would not be clear to 'most' dotnet devs. My colleague and I had no idea that would be the case.

[canton7]

My point is that dumping a whole expression to the runtime just as cause a single input property is a dynamic type feels harsh, thats all.

And the point that @Richiban and @yaakov-h were making is that method overload resolution depends on the types of that method's arguments, and with dynamic those aren't known until runtime. So the method resolution also needs to be deferred until runtime.

[micklaw]

Clearly that is where the gap in my knowledge comes in to play, so there is a TIL element here for me in there is nothing that can be done here in any capacity when dynamic is used.

Thank you for your time and effort.

[paulomorgado]

@micklaw, that's why I said you should open issues on those pages if you fill information is missing.

[TahirAhmadov]

I understand if an expression depends on a dynamic input, then the result becomes dynamic:

dynamic x = ...;
var y = x.Prop + x.Prop2; // y becomes dynamic

But in the OP, it has IEnumerable<dynamic>, and regardless of what the dynamic happens to be at runtime, IEnumerable<T> doesn't have awaiting methods (presumably, there are no extension methods in this case). What is the motivation to make IEnumerable<dynamic> to be dynamic?

[canton7]

No it isn't. Dynamic is far more than that. ExpandoObject is just one type which implements IDynamicMetaObjectProvider (DynamicObject is another, but there are many more). But dynamic lets you do things which don't use the IDynamicMetaObjectProvider machinery at all.

[CalinBunea]

No it isn't. Dynamic is far more than that. ExpandoObject is just one type which implements IDynamicMetaObjectProvider (DynamicObject is another, but there are many more). But dynamic let's you do things which don't use the IDynamicMetaObjectProvider machinery at all.

I guess I'll have to read more about dynamic mechanisms because is obviously I'm missing something. Thank you.

[CyrusNajmabadi]

Dynamic is basically an ExpandoObject

It isn't. The object can have any members and be anything at runtime.

And any of those members might have appropriate members in them that then make them legally awaitable.

[CyrusNajmabadi]

I still don't understand the motivation behind this.

It's not a matter of motivation. This is how dynamic has worked since it was introduced. :-)

It has always allowed full dynamism from everything involved. ExpandoObject is just one way to play on that space, but the system is much more powerful than that.

[HaloFour]

The motivation was to support integration between C# and dynamic languages like Javascript and Python. It was expected at the time that this would become an increasingly common scenario.

See: Dynamic Language Runtime