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@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@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/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 >>> 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 >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
