<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=""><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" 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=""><div class="gmail_extra"><div class="gmail_quote"><div class="">"Have the compiler specifically bless individual well-known types, e.g.<span class="Apple-converted-space"> </span><code class="">Python.PyVal</code><span class="Apple-converted-space"> </span>(or whatever it is eventually named) by baking in awareness of these types into the compiler. Such an approach would require a Swift evolution proposal to add a new type that conforms to this."</div><div class="">+1</div></div></div></div></div></blockquote><div>I have strong bias against special cases in the compiler (well, actually, against special cases in general ;-).</div><div>Imho it’s preferable to keep the compiler simple, and change it only for thinks you can’t do with a library.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" 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=""><div class="gmail_extra"><div class="gmail_quote"><div class="">I think there are a very finite number of programming languages Swift would like to have this kind of interop with, and i think having every new case reach into core team would also be a good opportunity to reevaluate that part of the language.</div></div></div></div></div></blockquote><div>I’m pro reevaluation, but what could be the outcome? This process only makes sense if it is an option to roll back changes that don’t work as well as expected.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" 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=""><div class="gmail_extra"><div class="gmail_quote"><div class="">IIUC, this is also the most controlled version of the proposal, and it prevents all abuses, while enabling the most seamless experience for python developers. So, it looks perfect to me.<br class=""></div></div></div></div></div></blockquote></div><br class=""><div class="">I may have missed some changes in direction, but afair, it was a strong point in the early revisions of the proposals that the suggested changes are useful in general, and not Python-specific…</div><div class="">Also, I don’t think anything can prevent all abuses (it’s an subjective classification anyways) — people might just use PyVals because dynamic behavior, and that would imho be a huge abuse.</div></body></html>