[swift-dev] deprecating -Ounchecked

[Erik Eckstein]

> On Nov 5, 2017, at 4:05 PM, Andrew Trick <atrick at apple.com> wrote:
> 
> 
> 
>> On Nov 3, 2017, at 12:45 PM, Slava Pestov via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>> 
>> 
>>> On Nov 3, 2017, at 8:31 AM, Erik Eckstein via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> 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). For example, it might happen that users see perf regressions from one release to another, using this option.
>> 
>> I would suggest going further and removing the code for -unsafe-remove-checks altogether. Even untested code has a cost in terms of maintainability.
>> 
>> Slava
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.

You are right, this is better.

> 
> -Andy
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20171105/1ba9361e/attachment.html>