<div dir="ltr">I tuned out the initial discussions of this proposal because there seemed to be a lot of noise centered around implementation/maintainability. I'm curious if the actual premise of the syntactic/sugar conversion has been discussed/debated yet? i.e. making dynamic/stringly calls look like normal calls is very clean, but it's also very misleading (by definition; they're not normal/safe/checked calls) with a potential net reduction in ergonomics.<div><br></div><div>Cleanliness is a double edged sword, which Swift already suffers at the hand of. Type inference and overloading are fantastic. Literal convertibles are magic. Omitting "redundant" types/descriptors from signatures is so right. But they (especially when combined) lead to a lot of Swift code ranging from unclear to meaningless at a glance, with a couple option-clicks per line necessary to extract exactly what's going on from the all knowing compiler. This is a hindrance in Xcode, and not possible if you've only got the text (like on GitHub).</div><div> But whereas these features only really effect code comprehension, the proposed syntactic conversion effects code comprehension and writing safe code. Usually in Swift you have to opt in at the call site to unchecked behaviour, but with these changes, working in a mixed pure Swift/Pythonic Swift environment, if you don't pay a good deal of attention to each object you're writing calls on (whether it conforms to the new protocol), you can write totally unchecked code by accident. Not to say the code comprehension itself isn't a problem — with type inferred/descriptor-cleaned code it's evident the information isn't there, so if something isn't clear there's an impetus to option-click/check it. With this dynamic-posing-as-checked code, the truth and the evidence is disguised.</div><div><br></div><div>Anyway, there's my primary concern. Has this been addressed yet? Has any thought been given to requiring '?'/'!' on these calls (or some other symbol, but this would retain some cleanliness..) to opt into the inherent fallibility and distinguish them visually?</div><div><br></div><div>Thanks,</div><div>Mathew</div><div><div class="gmail_extra"> <br><div class="gmail_quote">On Mon, Nov 27, 2017 at 6:04 AM, Chris Lattner via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I’d like to formally propose the inclusion of user-defined dynamic member lookup types.<br>
<br>
Here is my latest draft of the proposal:<br>
<a href="https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438" rel="noreferrer" target="_blank">https://gist.github.com/<wbr>lattner/<wbr>b016e1cf86c43732c8d82f90e5ae54<wbr>38</a><br>
<a href="https://github.com/apple/swift-evolution/pull/768" rel="noreferrer" target="_blank">https://github.com/apple/<wbr>swift-evolution/pull/768</a><br>
<br>
An implementation of this design is available here:<br>
<a href="https://github.com/apple/swift/pull/13076" rel="noreferrer" target="_blank">https://github.com/apple/<wbr>swift/pull/13076</a><br>
<br>
The implementation is straight-forward and (IMO) non-invasive in the compiler.<br>
<br>
-Chris<br>
<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>
</blockquote></div><br></div></div></div>