> On 4 Dec 2017, at 10:42, Vincent Esche via swift-evolution > <swift-evolution@swift.org> wrote: > > 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.
I would definitely not go as far as calling this proposal a language footgun. > On Mon, Dec 4, 2017 at 12:16 AM, Benjamin G via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > > > On Sun, Dec 3, 2017 at 8:26 PM, Chris Lattner via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > On Dec 3, 2017, at 11:03 AM, Magnus Ahltorp <m...@kth.se > <mailto:m...@kth.se>> wrote: > > > >> 4 Dec. 2017 02:40 Chris Lattner via swift-evolution > >> <swift-evolution@swift.org <mailto: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 > >> > >> <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. > > 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 <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <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
