On Nov 3, 2017, at 8:31 AM, Erik Eckstein via swift-dev <swift-dev@swift.org> 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 several issues: > 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.
That seems true regardless of how you spell it. > 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 don’t see that. It is either supported or not. If it is unsupported, it should be removed. > The second thing is, IMO, that -Ounchecked suggests that it’s just another > choice like -O. But I think we should encourage people to not use Ounchecked. 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. > 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. The cost of moving something exceed the cost of a simple “cleanup" IMO. > The third issue is that we now have -Osize. The -unsafe-remove-checks would > be orthogonal to -O and -Osize. > BTW, we should rename -O to -Ospeed for consistency (keeping -O as an alias > for -Ospeed). Ok, well that’s an issue that can be resolved in multiple different ways, including changing how you introduced -Osize. 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. 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. -Chris
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
