<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></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="">On Jun 12, 2016, at 6:05 AM, Alexander Momchilov <<a href="mailto:alexandermomchilov@gmail.com" class="">alexandermomchilov@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Aren't macros totally different?<div class=""><br class=""></div><div class="">Anyways, weren't macros rejected? I thought Swift was trying to avoid having the hefty reliance of preprocessor macros that C did.</div></div></div></blockquote><div><br class=""></div><div>Sorry I was not referring to C-style macros (i.e. preproc). I was referring to a macro language in the sense of the scala compiler macros or other languages that let you insert compile time code inside your source (like D). I was of the opinion that it would be a short step to support something like embedded SIL inside string literals. But Chirs ruled out compile time code execution stressing that it should not be a replacement for designing a great language. Maybe around 4 or 5, when the language is mature, then compile time code execution (macros) can be added</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 9, 2016, at 1:48 AM, L. Mihalkovic <<a href="mailto:laurent.mihalkovic@gmail.com" class="">laurent.mihalkovic@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">Chris has rules macros out-of-scope for 3.0. Who knows, maybe they'll be allowable in 4.0</div><div class=""><br class="">On Jun 9, 2016, at 1:41 AM, Alexander Momchilov via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class="">Preface: I know this is likely a large undertaking to implement, but I think it's worth it.<div class=""><br class=""></div><div class="">In addition to the typical compiler optimization of constant math expressions, some languages (such as D and C++) have support for running <a href="https://en.wikipedia.org/wiki/Compile_time_function_execution" class="">arbitrary functions at compile time</a> (with some constraints).</div><div class=""><br class=""></div><div class="">I see many advantages of this:</div><div class=""><ol class="MailOutline"><li class="">On iOS/OS X: it could precompute the UI and app initialization logic (wherever possible) to speed app load times</li><li class="">It can significantly speed up the initialization of applications with large static properties. E.g. large constant Dictionaries could be precomputed.</li><li class="">You could keep complex math expressions (including custom functions) in their unevaluated form, without the pressure to precompute them elsewhere and hardcode in the result.</li><li class="">Dynamic programming: expensive look-up tables could be precomputed. These wouldn't necessarily be large in size, but if their elements are especially expensive to compute, there would be a huge advantage to precomputing them.</li></ol><div class=""><br class=""></div></div><div class="">What do you guys think? Can you think of any other useful applications? Would it be worth the implementation effort?</div><div class=""><br class=""></div><div class=""><div class="">- Regards,<br class=""> Alexander Momchilov</div></div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></body></html>