<div dir="ltr">On Sat, Nov 11, 2017 at 12:39 PM, Joe Groff via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><span></span></div><div><span class=""><div></div><div><br></div><div><br>On Nov 11, 2017, at 10:12 AM, Chris Lattner <<a href="mailto:sabre@nondot.org" target="_blank">sabre@nondot.org</a>> wrote:<br><br></div><blockquote type="cite"><div><span>On Nov 11, 2017, at 6:52 AM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</span><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I don't think it's that localized. It's going to make call resolution massively more complicated. Through great pain and community anguish, we pushed ourselves to a model where argument labels are parts of the declaration name, not part of the call argument, and this would throw us straight back into the kinds of complications of dealing with overloaded name- and type-dependent behavior we're trying to get away from in the language.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I’m pretty sure it doesn’t, but good news: since Swift requires an implementation before the proposal can be officially reviewed, you will be able to look at the actual patch to make this decision.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>And the goal of the pitch phase is to hopefully save you the tears of trying to implement something if it's a bad idea.</span><br></blockquote><span></span><br><span>Appreciated. Fortunately I enjoy coding so it’s not that big of a deal for me.</span><br><span></span><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Swift is a dynamic language too, and tuples have enough metadata in them that you could get almost everything you want with an infix operator.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>This is really gross. The goal here is to make Python feel natural. If you oppose this proposal then we’ll have to find some other way to provide an elegant experience:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>x∫(0, "foo", bar: "bas”)</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>This is not going to be acceptable to users.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Is it? My choice of operator character is silly, but it's the same amount of syntactic overhead as an optional chain/force call. It's a fair sight better than x.call(args: ..., keywordArgs: ...), I hope you'd agree, and is something that works without any language change.</span><br></blockquote><span></span><br><span>Yes, I’m happy to explore that, and I agree this approach doesn’t require language changes. That said, there are three things you should understand:</span><br><span></span><br><span>1) Details matter. While you claim that there is some other operator character that could be awesome, I’m not seeing it. Can you try harder to come up with something that you think would be acceptable?</span><br><span></span><br><span>2) The point of the entire proposal is that a certain audience will be using the feature enabled by this (python interop) *a lot*, so ergonomics matter.</span><br><span></span><br><span>3) This feature (python interop) is aimed to get Python programmers to convert to Swift, not simply to ease friction for existing Swift programmers (most of whom are iOS developers, to whom this feature is completely irrelevant). Getting people to move from Python to Swift is a challenge, and syntax does actually matter. I hope we can agree that expanding the community of Swift developers is a laudable goal. </span><br></div></blockquote><div><br></div></span>Sure. I suggest it not as a final endpoint but as incremental progress you can make with the language today. If you can get some early adopters interested in moving from Python to Swift with some small warts now and the promise of refined syntax in the future, that could let you make progress while we work out the right final model for dynamic language interop.</div></div></blockquote><div><br></div><div>As a community member, I have to say that this part of the core team response to the pitch has been the most dismaying part. It is quite evident to all, I'm sure, that the ergonomics and approachability of Python is one of the major draws for its audience. If Python interop in Swift is to gain traction with that audience, it is pretty clear that anything short of `foo.bar(42)` is not going to cut it. Overall, the response to a proposed design to achieve that goal seems to be focused not on the design but on that goal itself, and the gist of the response I'm sensing is "not now, if ever," or "current Swift users first, new Swift users later." If a final model for dynamic language interop is what's necessary before any headway is made in this space, then it would seem to me that it is tantamount to shutting down the conversation here.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Since you have long term ambitions in this space, I think it'd pay off to consider more infrastructurally-heavy features with bigger long-term payoffs.<span class=""><br><blockquote type="cite"><div><span></span><br><blockquote type="cite"><span>You mentioned variadics as being inadequate for your purposes as a considered alternative, but a variadics model that wasn't based on type erasure to arrays and kept runtime type information about the argument tuple that was passed in, along with better reflection APIs for accessing that type info, might lead to something you can use by incrementally improving the expressivity of existing language features instead of adding new ones.</span><br></blockquote><span></span><br><span>I’m not sure what you mean by this: variadics are fine. The hard part is getting the keyword arguments for a call dynamically. Can you point to what you’re referring to in the proposal?</span><br></div></blockquote><div><br></div></span><div>I was referring to your comment in this section:</div><div><br></div><div><h3 style="box-sizing:border-box;margin-top:24px;margin-bottom:16px;line-height:1.25"></h3><blockquote type="cite"><h3 style="box-sizing:border-box;margin-top:24px;margin-bottom:16px;line-height:1.25"><font size="3"><span style="background-color:rgba(255,255,255,0)">Statically checking for exact signatures</span></font></h3><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px"><span style="background-color:rgba(255,255,255,0)">This proposal does not allow a type to specify an exact signature for the callable - a specific number of parameters with specific types. If we went down that route, the best approach would be to introduce a new declaration kind (which would end up being very similar to get-only subscripts) since, in general, a type could want multiple concrete callable signatures, and those signatures should participate in overload resolution.</span></p><span class=""><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px"><span style="background-color:rgba(255,255,255,0)">While such a feature could be interesting for some use cases, it is almost entirely orthogonal from this proposal: it addresses different use cases and does not solve the needs of this proposal. It does not address our needs because even a variadic callable declaration would not provide access to the keyword argument labels we need.</span></p></span></blockquote><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px">We know our variadics model is inadequate in a lot of ways. I was suggesting there are ways of extending it that could allow the 'static' and 'dynamic' callable protocol to be one thing, or have a subscript-like `call` special form.</p><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px">-Joe</p></div><br><blockquote type="cite"><div><span>-Chris</span><br><span></span><br></div></blockquote></div></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div>