You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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.
The text was updated successfully, but these errors were encountered:
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.
This addresses scenario #135
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 theOption Strict
setting in that file or project. TheDynamic
type would be persisted into metadata or read from metadata using the sameDynamicAttribute
encoding C# uses to facilitate round-tripping between the languages.Questions
Should
Dynamic
be a reserved keyword?Semantically contextual keywords such as
dynamic
andvar
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?Today this code throws an exception because rather than resolving the entire
ToString
method group at run-time and letting overload resolution choose theToString(String)
overload,ToString
is resolved early-bound to the statically available no-argToString()
overload and the result of that invocation (a string) is indexed passing "C02" (implicitly converted to an integer) as theindex
parameter of theChars
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 useDynamic
might behave subtly different even though the vast majority of users would probably expect it to be 100% the same as usingObject
today.Dynamic
and remove any behavior or restriction fromObject
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
andDynamic
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.The text was updated successfully, but these errors were encountered: