{"id":21983,"date":"2018-06-29T16:02:31","date_gmt":"2018-06-29T20:02:31","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=21983"},"modified":"2018-07-18T14:48:34","modified_gmt":"2018-07-18T18:48:34","slug":"exploring-dynamicmemberlookup","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2018\/06\/29\/exploring-dynamicmemberlookup\/","title":{"rendered":"Exploring @dynamicMemberLookup"},"content":{"rendered":"

Olivier Halligon<\/a>:<\/p>\n

This proposal had some controversy, and one thing I didn’t personally like on this new feature is that it meant that typed annotated with @dynamicMemberLookup<\/code> would not, by design, show any potential compilation error. Which is understandable, as the whole need for that proposal was to be able to call properties which we didn’t know at compile-time.<\/p>

But this also meant that once the type was annotated with @dynamicMemberLookup<\/code>, you wouldn’t be able to choose at call-site if you wanted an expression to allow dynamic member lookup or wanted the expression on that type to be type-checked.<\/p>

[…]<\/p>

The solution is actually quite short to implement. We’ll create a ^<\/code> postfix operator that will wrap the instance it’s applied on into some proxy object that is the one being @dynamicMemberLookup<\/code>. That proxy object will just wrap the dictionary we applied ^<\/code> on, and on dynamic lookup, will search the key in the dictionary to return the corresponding value (if it exists).<\/p>

[…]<\/p>

In the playground attached below, I’ve explored that idea a bit more, by allowing another syntax. This one looks more like creating a context or scope in which everything we call is dynamically looked up (instead of looking like chaining ^<\/code> calls)<\/p><\/blockquote>\n\n

Ole Begemann<\/a> (tweet<\/a>):<\/p>\n

Here are some non-obvious things you can do with @dynamicMemberLookup<\/code>:<\/p>\n