On Nov 10, 2017, at 8:43 PM, Chris Lattner via swift-dev <swift-dev@swift.org> wrote:
>> 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. I agree with Chris here. This is essentially a proposal to change a user facing aspect of the Swift language. I don’t think all technical changes need to go through Swift evolution, but certainly ones that might have notable impact on users should be surfaced and discussed there. This is one of them. > >> 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. I agree 100%. I think this needs an evolution proposal. > >>> 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. I think there is a separation of concerns here. Clearly the fate of the language mode provided by -Ounchecked should be discussed on swift-evolution. This concerns the decision to remove it or keep it around, etc. The compiler flags have user impact because people use them. I am mixed on whether every flag change needs to go through an evolution proposal, but in this case because it is tied with the fate of this language mode we should consider it altogether. > > -Chris > > > _______________________________________________ > swift-dev mailing list > swift-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-dev _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
