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 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 swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution