On Dec 3, 2017, at 11:03 AM, Magnus Ahltorp <m...@kth.se> wrote:
>> 4 Dec. 2017 02:40 Chris Lattner via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> That’s a good principle.  However, a dynamic member lookup is just a member 
>> lookup.  By that principle, it should look like a member lookup :-)
>> Further, I incorporated some of the conversation with Matthew into the 
>> proposal, showing how adding even a single sigil to dynamic member lookup to 
>> distinguish it is problematic:
>> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#increasing-visibility-of-dynamic-member-lookups
>> Further, adding something like .dynamic would completely undermind the 
>> proposal.  You can already write:
>>      x.get(“foo”).get(“bar”)
>> having to write:
>>      x.dynamic.foo.dynamic.bar
>> has no point.
> This example shows what many on this list don't believe: that any Swift 
> method or member access can fail. If the return value of this "get" method is 
> an IUO, or not an Optional at all, and doesn't throw, then the expression 
> would have to fail hard if "foo" didn't resolve to something meaningful.
> The most common argument against this proposal is that someone could make an 
> API using Dynamic Member Lookup that could fail even though it is not 
> apparent to the caller. But, as we see in the example, this is just as 
> possible today.

Correct.  The argument also fails to recognize that (when bridging to a dynamic 


Is a completely dynamic method call which can fail (or return IUO), as is:


And that this is true with no changes to Swift.  The claim that such a thing is 
counter to the design of Swift is completely perplexing to me.


swift-evolution mailing list

Reply via email to