[swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Benjamin G]

On Sun, Dec 3, 2017 at 8:26 PM, Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:

> On Dec 3, 2017, at 11:03 AM, Magnus Ahltorp <map at kth.se> wrote:
> >
> >> 4 Dec. 2017 02:40 Chris Lattner via swift-evolution <
> swift-evolution at 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/b016e1cf86c43732c8d82f90e5ae54
> 38#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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171204/50524663/attachment.html>