<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">Le 30 juil. 2017 à 12:23, Gor Gyolchanyan via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 30, 2017, at 1:03 PM, Daniel Vollmer via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hello,<br class=""><br class=""><blockquote type="cite" class="">On 30. Jul 2017, at 08:52, Gor Gyolchanyan via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""></blockquote><br class="">[snip]<br class=""><br class=""><blockquote type="cite" class="">This is a huge undertaking, but if we split it in two parts: "executing at compiletime" and "exposing swift’s frontend”, this could surely be done by Swift 5. From all the ideas that I’ve had or seen on this mailing list, in my opinion this is the most ground-braking, powerful and useful, so I’d be willing to work day and night to help implement this.<br class=""></blockquote><br class="">As you say, I agree that these are separate concepts (compile-time evaluation vs. meta-programming), but the first is surely going to be helpful for the second.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">That’s exactly what I had in mind: compiletime execution comes first, meta-programming gets built on top of it.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">As far as I can tell, compile-time evaluation would probably lose most / all of the stdlib. I’d hate to replicate parts of the standard library in a restricted subset of the language so that they are available in `constexpr` mode (which is what 80% of C++’s template meta-programming libraries do). I’m also not quite sure how to make that feature work with cross-compilation when host and target differ in architecture.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I disagree. Most of the standard library is in protocols and small generic wrapper structures, which are prime candidates for compile-time evaluation. Even if Foundation has to be dropped (which is actually not that big of a deal), I think adapting the standard library to be less architecturally dependent to make it accessible in compiletime wouldn’t be such a big problem considering that it is already largely driven by protocols.</div><div class="">I think the architectural differences are negligible largely due to LLVM IR, which is portable (even byte ordering is taken into account).</div></div></div></div></blockquote><div><br class=""></div><div>Why this long due myth subsist, LLVM IR is not portable. You can produce portable IR by limiting the scope of the input language, but it does not even provides a way to express sizeof(long) in a architecture independent way. And I don’t even mention the type layouts.</div></div><br class=""></body></html>