> On Nov 4, 2017, at 9:52 PM, Erik Eckstein <eeckst...@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.

-Chris


_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Reply via email to