<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" 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:<br class=""><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" 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 class=""><br class=""></div><div class="">There are several issues:</div><div class="">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></div></div></blockquote><div><br class=""></div><div>That seems true regardless of how you spell it.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div 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.</div></div></div></div></blockquote><div><br class=""></div>I don’t see that. It is either supported or not. If it is unsupported, it should be removed.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class="">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. </div></div></div></div></blockquote><div><br class=""></div><div>I don’t necessarily agree. -Ounchecked isn’t “bad”. It is a feature in service of a few specific use cases. If you’d like to remove it, then you should publicly advertise that, and justify it based on the lack of users. Don’t cast value judgements against it and claim it should be removed on moral grounds.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class="">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></div></div></blockquote><div><br class=""></div><div>The cost of moving something exceed the cost of a simple “cleanup" IMO.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class="">The third issue is that we now have -Osize. The -unsafe-remove-checks would be orthogonal to -O and -Osize.</div><div class="">BTW, we should rename -O to -Ospeed for consistency (keeping -O as an alias for -Ospeed).</div></div></div></div></blockquote><br class=""></div><div>Ok, well that’s an issue that can be resolved in multiple different ways, including changing how you introduced -Osize.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>In short, I’d recommend that you pitch removing -Ounchecked on swift-evolution. That seems like the path you want, because then you could completely remove the codepaths in question.</div><div><br class=""></div><div>-Chris</div><div><br class=""></div><br class=""></body></html>