<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">On Nov 11, 2017, at 6:52 PM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:<br class=""><div><blockquote type="cite" class=""><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class=""><div class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="">In point of fact, Swift already has the feature you are referring to. It just spells it with square brackets instead of parentheses. A simple change to the punctuation character has much less point than the proposal that I’m pitching.</div></div></blockquote><div class=""><br class=""></div><div class="">This is true if you squint, but I imagine a design for callable types would include some </div><div class=""> differences other than just punctuation.</div></div></blockquote></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">I think there was a pretty good discussion of this distinction in the SE-0021 timeframe. Specifically, subscripts model storage while callable would model functions. This means that subscripts can be used in a key path while callable would not (at last for now). </div></div></blockquote><div><br class=""></div><div>Sure, subscript getters are more general than calls in that respect, I agree.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">On the other hand, I would want to see callables implicitly convert to a value of a compatible function type (possibly through a subtype relationship).</div></div></blockquote><div><br class=""></div><div>Subscripts are generalizations of the property model in Swift. We’ve discussed being able to curry the getter of a property, so I don’t see why currying the getter of a subscript should work any different. This would directly provide the functionality you’re referring to.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""> Without this capability the syntactic illusion is only half complete. The callable feels like a function when used directly but not when it is assigned to a function type or passed elsewhere - it must be explicitly be wrapped in a closure and the arguments forwarded. First-class callable types are a syntactic sugar feature and as such if they exist they should be usable syntactically in all of the same ways functions are.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Read-only subscripts are ok as a workaround in absence of first-class callable types (although I think in many ways just using `call` is better). Nevertheless, they are a workaround and can never be more than that because of the fundamental difference in what they model.</div></div></blockquote><br class=""></div><div>Please don’t misunderstand me. I’m not saying that:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>let a = x[foo: 42, “bonk”, bar: 17]</div><div><br class=""></div><div>is “better” than:</div><div><br class=""></div><div><div><span class="Apple-tab-span" style="white-space:pre"> </span>let a = x(foo: 42, “bonk”, bar: 17)</div><div class=""><br class=""></div></div>when x is a functor or something else function like. Syntax matters: it is the principle way that language communicates to programmers, and sending an indexing connotation is very different than sending a call connotation. My point is simply that we already have the ability to *express* this concept, so users have a way to solve a problem (even in a suboptimal way). <div class=""><br class=""></div><div class="">In contrast, we do not have a way to express the dynamically callable form, which is the subject of my proposal. The workaround is not a change of one punctuation character to another, it is a significantly heavier syntactic form like x.call(…) or perhaps Joe’s proposal of introducing weird punctuation.<div class=""><br class=""></div><div class="">In any case, as I have reiterated many times, I simply want to solve the Python import problem. I am not wed to this approach. If there is another approach that provides a equal (or better) result, then I’m super interested to hear about it. The only alternative that I’m aware of is to burn support for Python into the Swift compiler, which I’m pretty opposed to doing: not only is it significantly more complexity than the proposals required to implement this in libraries, it also signs us up to do the same for Perl, Ruby, Javascript, …...</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div></div></body></html>