On Dec 3, 2017, at 11:03 AM, Magnus Ahltorp <[email protected]> wrote:
>
>> 4 Dec. 2017 02:40 Chris Lattner via swift-evolution
>> <[email protected]> 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
language):
x+y
Is a completely dynamic method call which can fail (or return IUO), as is:
x[i]
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.
-Chris
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
