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

[Vincent Esche]

>
> 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 at swift.org> wrote:

>
>
> 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/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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
> _______________________________________________
> 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/efc5a027/attachment.html>