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

[Wallacy]

May the question is a little silly. But can this proposal be made on top of
property behaviors? ( or the inverse).


We already talk about *new kinds* of getters and setters, possibly new
sintaxes to call then... I don’t now, maybe I’m overlooking the problem,
but feels that , wherever we choose here should be userfull for other
things in the language.



Em seg, 4 de dez de 2017 às 06:42, Vincent Esche via swift-evolution <
swift-evolution at swift.org> escreveu:

> 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/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 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
>>
>>
> _______________________________________________
> 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/801affbb/attachment.html>