<div dir="ltr">I'd guess the point is that the generics system isn't meant to force the compiler to perform the sorts of things C++'s (Turing-complete) template system can:<div><br><div><div><span style="font-family:monospace,monospace"> template<size_t... F></span><br></div><div><font face="monospace, monospace"> struct Fibonacci { };</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace"> // API</font></div><div><font face="monospace, monospace"> template<size_t n></font></div><div><font face="monospace, monospace"> struct Fibonacci<n> {</font></div><div><font face="monospace, monospace"> static constexpr size_t value = Fibonacci<n, 1, 0>::value;</font></div><div><font face="monospace, monospace"> };</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace"> // Recursive implementation</font></div><div><font face="monospace, monospace"> template<size_t n, size_t Fn, size_t Fm></font></div><div><font face="monospace, monospace"> struct Fibonacci<n, Fn, Fm> {</font></div><div><font face="monospace, monospace"> static constexpr size_t value = Fibonacci<n-1, Fn+Fm, Fn>::value;</font></div><div><font face="monospace, monospace"> };</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace"> // Base case</font></div><div><font face="monospace, monospace"> template<size_t Fn, size_t Fm></font></div><div><font face="monospace, monospace"> struct Fibonacci<0, Fn, Fm> {</font></div><div><font face="monospace, monospace"> static constexpr size_t value = Fn;</font></div><div><font face="monospace, monospace"> };</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace"> int main() {</font></div><div><font face="monospace, monospace"> printf("F(200): %zu\n", Fibonacci<200>::value);</font></div><div><font face="monospace, monospace"> return 0;</font></div><div><font face="monospace, monospace"> }</font></div></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><div>Jacob<br></div></div></div></div>
<br><div class="gmail_quote">On Sat, Jan 23, 2016 at 11:17 PM, Michael Henson via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">In the swift/docs/Generics.rst documentation, I see:<div><br></div><div>"</div><div><div>As important as the goals of a feature are the explicit non-goals, which we don't want</div><div>or don't need to support:</div></div><div>* Compile-time "metaprogramming" in any form</div><div>* Expression-template tricks a la Boost.Spirit, POOMA</div><div>"</div><div><br></div><div>What kinds of things count as compile-time metaprogramming? I've been tinkering with some ideas related to the type system and having a more specific description here might help me pare many / most / all of them down.<br><br>Mike</div></div>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div></div></div>