> > I think the argument basically is "let's not add another footgun" (because > the design of Swift , for example regarding null handling, is to have less > footguns than other languages). The fact that there are footguns in swift > isn't an argument for adding new ones.
Couldn’t have said it better. This is what it all boils down to. On Mon, Dec 4, 2017 at 12:16 AM, Benjamin G via swift-evolution < swift-evolution@swift.org> wrote: > > > On Sun, Dec 3, 2017 at 8:26 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > >> 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/b016e1cf86c43732c8d82f90e5ae >> 5438#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. >> > > I think the argument basically is "let's not add another footgun" (because > the design of Swift , for example regarding null handling, is to have less > footguns than other languages). The fact that there are footguns in swift > isn't an argument for adding new ones. > > > >> >> -Chris >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
