<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=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 2, 2017, at 8:50 PM, Chris Lattner <<a href="mailto:clattner@nondot.org" class="">clattner@nondot.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On Nov 2, 2017, at 9:52 AM, Erik Eckstein via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:<br class=""><br class="">Hi,<br class=""><br class="">I’d like to propose to deprecate the -Ounchecked swift optimization mode.<br class=""><br class="">The -Ounchecked mode actually contradicts one of the main goals of swift: to be a safe language.<br class="">In the past we didn’t see lot of significant performance differences compared to -O (there were some improvements but also some regressions).<br class="">Also, we want to reduce the effort of maintaining too many different optimization modes, especially because we recently added -Osize.<br class=""><br class="">Deprecating would mean that we map -Ounchecked to -O.<br class=""><br class="">If you have any comments or concerns, please let me know<br class=""></blockquote><br class="">What’s the motivation for this? What problem does it solve?<br class=""></div></div></blockquote><div><br class=""></div><div>There are several issues:</div><div>First, Ounchecked does not come for free. To really support this mode we would have to constantly track performance metrics for this, investigate performance/codesize regressions, etc. This is a lot of effort.</div><div><br class=""></div><div>So if we replace Ounchecked with an option -unsafe-remove-checks (similar to -assume-single-threaded), as Johannes suggested, this is more like a “at your own risk” thing (regarding performance). For example, it might happen that users see perf regressions from one release to another, using this option.</div><div><br class=""></div><div>The second thing is, IMO, that -Ounchecked suggests that it’s just another choice like -O. But I think we should encourage people to <i class="">not</i> use Ounchecked. I think it’s fine if experienced developers, who know what they are doing, use -unsafe-remove-checks, but we should not promote this mode in a prominent place like in the -O namespace. This is just my personal opinion and I’m sure some people have other opinions on this.</div><div><br class=""></div><div>The third issue is that we now have -Osize. The -unsafe-remove-checks would be orthogonal to -O and -Osize.</div><div>BTW, we should rename -O to -Ospeed for consistency (keeping -O as an alias for -Ospeed).</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">Swift isn’t a "strict safety at all costs” language. It is a pragmatic language which aims to give people tools to solve problems. One of the nice things about -Ounchecked is that it provides an easy way to get a data point about the cost of runtime checks.<br class=""><br class="">-Chris<br class=""><br class=""></div></div></blockquote></div><br class=""></body></html>