<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>I like this proposal and I like the general approach even more. Allow the programmer to make an assertion about performance and receive a warning or error when the compiler cannot guarantee the assertion will be met. This will make it easier to reason about the performance of code in a language where performance is extremely reliant on optimizations.<br><br>Sent from my iPad</div><div><br>On Dec 5, 2015, at 7:55 AM, T.J. Usiyan <<a href="mailto:griotspeak@gmail.com">griotspeak@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div><div>## Introduction</div><div><br></div><div>Tail call optimization can be a powerful tool when implementing certain types of algorithms. Unfortunately, ARC's semantics interfere with our ability to handle all possible cases of tail call recursion. An attribute, similar to Scala's `tailrec`, along with LLVM warnings, could allow a clear indicator of when such optimizations are not guaranteed to work.</div><div><br></div><div>## Motivation</div><div><br></div><div>LLVM will, currently, perform tail call optimization when possible cannot guarantee such optimizations. ARC can interfere with tail call recursion by inserting a method call after the intended 'last' recursive call. The ability to insert this call is fundamental to ARC and, because of this, swift developers currently have no insight into when TCO can/will occur.</div><div><br></div><div>``` swift</div><div>func fact(input: Int) -> Int {</div><div> func _fact(n: Int, value: Int) -> (n: Int, value:Int) {</div><div> if n <= 0 {</div><div> return (0, value)</div><div> } else {</div><div> return _fact(n - 1, value: n * value)</div><div> }</div><div> }</div><div><br></div><div> return _fact(input, value: 1).value</div><div>}</div><div>```</div><div>In the provided example, the developer can be sure that tail call optimization is possible but, without either a universal guarantee or something like the proposed attribute, there is no wait to be sure that such an optimization will occur.</div><div><br></div><div>## Proposed solution</div><div><br></div><div>Providing an attribute would provide developers with concrete klnowledge of when TCO can and will be performed by LLVM in compiling their swift code. </div><div><br></div><div>``` swift</div><div>func fact(input: Int) -> Int {</div><div><span class="" style="white-space:pre"> </span>@tailrec</div><div> func _fact(n: Int, value: Int) -> (n: Int, value:Int) {</div><div> ...</div><div>```</div><div>With this attribute, the developer can express the desire for TCO and warnings can be emitted if TCO cannot be guaranteed. If there are currently only a few such cases, developers are made aware of what those cases are and can design implementations with this information at hand. As LLVM's ability to provide TCO increases, the allowed cases simply grow with no effect for the initial narrow cases.</div><div><br></div><div><br></div><div>## Detailed design</div><div>In an ideal situation, implementation of this feature can consist solely of the attribute and output from LLVM indicating whether or not the requested ptimization can be guaranteed. This proposal does not call for an expansion of accepted cases.</div><div><br></div><div>## Impact on existing code</div><div><br></div><div>This should not have any breaking impact as it is strictly additive and diagnostic.</div><div><br></div></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=eLFMrKDT8iBxZ-2Fbnk-2BZqvSchNN-2FvYXdceA0T7VxwkAfuWY7hzY2cFnUJrE0HuO9xpf4l-2BWGHgp8W8CkCnq4qjRN2sDRL8yQdSZSU3CrysfiQ3PvgXoZ5cFWhNEbiZkMVqso1R03eEDhn7StRQriiXgpHAoeempa-2FWCrzNBvdAjmDKIXH8Z5hw-2BrL5Xy8eL2ehX74BztpsIC9GRHPTXvVjVaQmHWnOF1qVabjRz1MgQA-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;">
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>