> On Nov 5, 2017, at 4:05 PM, Andrew Trick <atr...@apple.com> wrote: > > > >> On Nov 3, 2017, at 12:45 PM, Slava Pestov via swift-dev <swift-dev@swift.org >> <mailto:swift-dev@swift.org>> wrote: >> >> >>> On Nov 3, 2017, at 8:31 AM, Erik Eckstein via swift-dev >>> <swift-dev@swift.org <mailto:swift-dev@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 > > >
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
