Re: [swift-dev] deprecating -Ounchecked

> On Nov 3, 2017, at 8:57 PM, Chris Lattner via swift-dev > wrote: > > 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

Re: [swift-dev] deprecating -Ounchecked

On Nov 3, 2017, at 8:31 AM, Erik Eckstein via swift-dev wrote: >>> >>> Deprecating would mean that we map -Ounchecked to -O. >>> >>> If you have any comments or concerns, please let me know >> >> What’s the motivation for this? What problem does it solve? > > There are

Re: [swift-dev] deprecating -Ounchecked

> On Nov 3, 2017, at 8:31 AM, Erik Eckstein via swift-dev > wrote: > > 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).

Re: [swift-dev] deprecating -Ounchecked

> On Nov 2, 2017, at 8:50 PM, Chris Lattner wrote: > > >> On Nov 2, 2017, at 9:52 AM, Erik Eckstein via swift-dev >> wrote: >> >> Hi, >> >> I’d like to propose to deprecate the -Ounchecked swift optimization mode. >> >> The -Ounchecked mode

Re: [swift-dev] deprecating -Ounchecked

> On Nov 2, 2017, at 1:56 PM, Thomas Roughton via swift-dev > wrote: > > A -1 from me to deprecating the mode. I’ve been using Swift in > high-performance situations such as in a game engine, where in particular > thing like integer overflow checks become a measurable