[swift-dev] deprecating -Ounchecked

Chris Lattner clattner at nondot.org
Fri Nov 10 22:43:09 CST 2017

> On Nov 4, 2017, at 9:52 PM, Erik Eckstein <eeckstein at apple.com> wrote:
>>> Are compiler flags within the scope of the evolution process? -Osize has no effect on source compatibility or any other user-visible aspect of the language itself.
>> I don’t think there is an official policy, but IMO, all major new user visible features are in scope for evolution.
> swift evolution is for the "Swift language and the public interface of the Swift standard library” (which makes sense IMO).

This is probably what some web page literally says, but that is not the actual intent.  It is for important user impacting changes to be properly reviewed by the community.  Command line arguments seem to meet the bar to me.

> So command line options don’t need to go through the evolution process. For example, there could be another swift compiler, which is 100% swift compatible but provides a different option set.

I very much disagree with this, but feel free to start a thread asking about this on the evolution list.  Others may agree with you.

> About the naming convention: removing runtime checks is not really an optimization mode. It’s really more comparable to -assume-single-threaded (which is maybe as important as removed runtime checks for some users). So I think it makes sense to “rename” Ounchecked.

Sure, but “what’s right” is not the metric here.  Changes have to be measured against their user impact.  This is just as true for things that will break people’s makefiles as things that break their source.  Both break the build.

>> 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.
> I don’t agree. Command line options are the “UI” of a swift compiler but not of the swift language.

We are both welcome to our opinions, but your and my opinions aren’t what matters, we should ask the community and swift core team as a whole.


More information about the swift-dev mailing list