Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamic pseudo-type to enable late-binding per value #136

Closed
AnthonyDGreen opened this issue Jul 12, 2017 · 1 comment
Closed

Dynamic pseudo-type to enable late-binding per value #136

AnthonyDGreen opened this issue Jul 12, 2017 · 1 comment

Comments

@AnthonyDGreen
Copy link
Contributor

This addresses scenario #135

Dim someObject As Dynamic = ...
someObject.LateBoundCall()

This would be identical (or virtually identical) to C#s; if a value has the type Dynamic; it's legal to late-bind to that value and implicitly convert that value to any type regardless of the Option Strict setting in that file or project. The Dynamic type would be persisted into metadata or read from metadata using the same DynamicAttribute encoding C# uses to facilitate round-tripping between the languages.

Questions

  • Should Dynamic be a reserved keyword?
    Semantically contextual keywords such as dynamic and var have caused more suffering than any good they've done.

  • Should Dynamic force any invocations to be late-bound or will it still resolve object members early as VB does today?

Option Strict Off
Dim obj As Object = 1
Console.WriteLine(obj.ToString("C02"))

Today this code throws an exception because rather than resolving the entire ToString method group at run-time and letting overload resolution choose the ToString(String) overload, ToString is resolved early-bound to the statically available no-arg ToString() overload and the result of that invocation (a string) is indexed passing "C02" (implicitly converted to an integer) as the index parameter of the Chars default property. This conversion, of course, fails (this was a customer reported issue). Instead, Dynamic could break with the current late-binding semantics and always resolve members late-bound.

The reason VB does this today is because if it didn't then all expressions involving Object would always be late-bound, which would be a performance fail of epic proportions. Dynamic wouldn't have to play two roles so we could break with existing behavior in this specific case. The consequence of this would be that code migrated to use Dynamic might behave subtly different even though the vast majority of users would probably expect it to be 100% the same as using Object today.

  • Is there a way (like an Option Dynamic) that can enable Dynamic and remove any behavior or restriction from Object that's a consequence of it being VB's late-bound type (e.g. enabling extension methods on Object)?

Having watched the bug tail on this during the Roslyn re-implementation I can say that having both an Object and Dynamic type is very expensive. It's a large implementation cost, testing cost, and bug tail for a feature the fundamentally let's VB customers do something they can already do, albeit in a more intentional way, so this proposal isn't by any means a slam dunk.

@AnthonyDGreen
Copy link
Contributor Author

The VB LDM looked at this issue on August 23rd and rejected this proposal. This proposal either introduced a very subtly different concept of late-binding to the language vs Object late-binding, or it just duplicated existing functionality entirely. #117 was simpler and gets the job done without new concepts or syntax.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant