<div dir="ltr">I'm sure the implementation is fine, and I'm not criticising the proposal's intent/concept, least of all simply because it might be misused (because everything can and is).<div><br></div><div>Instead, I firmly believe — not to say I necessarily *deserve* a contrary explanation/argument if no one thinks this is a big deal, but just to be clear.. — that it is clean but fundamentally misleading (and thus potentially non-ergonomic) to transparently convert `Python.open(filename)` to `Python.get(member: "open")(filename)`.</div><div>The former line reads as "this lines calls this Swift function the compiler knows exists, as usual", and the latter reads as "this line looks for/tries to call something that may exist" — two very/importantly different things, and you will only be able to tell the difference by option-clicking the call site.</div><div>When we want to deal with a value that may not exist at runtime (an optional), there's extra syntax ('?') for that. It seems like the same thing for a function/call that may not exist *might* be appropriate. Equally happy to hear why not.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 27, 2017 at 6:30 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@nondot.org" target="_blank">clattner@nondot.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Nov 27, 2017, at 6:37 AM, Mathew Huusko V <<a href="mailto:mhuusko5@gmail.com">mhuusko5@gmail.com</a>> wrote:<br>
> I tuned out the initial discussions of this proposal because there seemed to be a lot of noise centered around implementation/<wbr>maintainability.<br>
<br>
</span>There was some noise, but as I believe the patch shows, it was misplaced.<br>
<span class=""><br>
> 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.<br>
<br>
</span>In fact, the calls are fully type safe and checked. The JSON example shows that.<br>
<br>
I think what you’re getting at here is that there is opportunity to misuse this feature. It is certainly not something that every one should use commonly on their types: it’s a power feature that is extremely important for some narrow cases.<br>
<br>
I’ll observe that this is exactly the sort of feature that Swift traditionally includes, and there are many examples of this: generalized operator overloading, the ability to syntax extend almost everything in the language (e.g. literals), user defined pattern matching in switches, etc.<br>
<span class=""><br>
> 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?<br>
<br>
</span>This feature isn’t unsafe at all, I’m not sure why that would be appropriate.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Chris<br>
<br>
<br>
</font></span></blockquote></div><br></div>