<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 10:51 PM, Chris Lattner 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 10:23 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; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Nov 3, 2017, at 8:57 PM, Chris Lattner 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="">Random question: when did you introduce -Osize, and why didn’t it go through the evolution process? If this is a major flag that you expect users to interact with (not some obscure debugging feature) then it is part of the “UI" of Swift and seems subject to swift-evolution’s process.</span></div></blockquote></div><br class=""><div class="">Are compiler flags within the scope of the evolution process? -Osize has no effect on source compatibility or any other user-visible aspect of the language itself.</div></div></div></blockquote><br class=""></div><div class="">I don’t think there is an official policy, but IMO, all major new user visible features are in scope for evolution.</div></div></div></blockquote><div><br class=""></div><div>swift evolution is for the "Swift language and the public interface of the Swift standard library” (which makes sense IMO).</div><div>So command line options don’t need to go through the evolution process. For example, there could be another swift compiler, which is 100% swift compatible but provides a different option set.</div><div><br class=""></div><div>But of course, we should discuss Ounchecked on swift-dev and that’s what we are doing now.</div><div><br class=""></div><div>So far I got the feedback that some people still want to disable runtime checks and that’s perfectly fine.</div><div>There is no problem in keeping that code generation option in the compiler (and in fact it’s only a very small check in the optimizer) and we will test that it is functional correct. But we - the swift perf team - probably won’t have capacity to maintain performance tracking of this mode (e.g. checking and investigation of perf regressions). But hey, swift is an open source project and everyone who is interested can invest effort in this.</div><div><br class=""></div><div>About the naming convention: removing runtime checks is not really an optimization mode. It’s really more comparable to -assume-single-threaded (which is maybe as important as removed runtime checks for some users). So I think it makes sense to “rename” Ounchecked.</div><div><br class=""></div><div><br class=""></div><blockquote type="cite" class="">Random question: when did you introduce -Osize, and why didn’t it go through the evolution process? If this is a major flag that you expect users to interact with (not some obscure debugging feature) then it is part of the “UI" of Swift and seems subject to swift-evolution’s process.<br class=""></blockquote><div><br class=""></div>I don’t agree. Command line options are the “UI” of a swift compiler but not of the swift language.</div><div><br class=""></div><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=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div><br class=""></div>_______________________________________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-dev<br class=""></div></blockquote></div><br class=""></body></html>