<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 3, 2017, at 12:45 PM, Slava Pestov via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</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=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 3, 2017, at 8:31 AM, Erik Eckstein via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">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.</span></div></blockquote></div><br class=""><div class="">I would suggest going further and removing the code for -unsafe-remove-checks altogether. Even untested code has a cost in terms of maintainability.</div><div class=""><br class=""></div><div class="">Slava</div></div></div></blockquote><br class=""></div><div>If we have an -unsafe-remove-checks option, then it will be tested. In this particular case, maintaining the functionality is insignificant, but the feature is fairly useful for evaluating the cost of checks in small benchmarks without rewriting the source.</div><div><br class=""></div><div>Supporting a few unit tests is completely different from constantly tracking performance of this mode and investigating regressions. I agree with Erik that it’s not worth continuing to do this.</div><div><br class=""></div><div>The spelling of the option does matter. -Oxxx carries some QoI expectations and implies that we are evaluating performance of that mode in every release cycle. We don’t want to do that.</div><div><br class=""></div><div>I do not agree that -Ounchecked should be mapped to -O. Lying to the user is never the right answer. It could be mapped to some internal option name with a deprecation warning.</div><div><br class=""></div><div>-Andy</div><div><br class=""></div><div><br class=""></div><br class=""></body></html>