deprecating -Ounchecked

Development Compiler
1

Hi,

I’d like to propose to deprecate the -Ounchecked swift optimization mode.

The -Ounchecked mode actually contradicts one of the main goals of swift: to be a safe language.
In the past we didn’t see lot of significant performance differences compared to -O (there were some improvements but also some regressions).
Also, we want to reduce the effort of maintaining too many different optimization modes, especially because we recently added -Osize.

Deprecating would mean that we map -Ounchecked to -O.

If you have any comments or concerns, please let me know

Thanks,
Erik

2

Definitely a +1 from me, a haven't recently seen much of a difference either.

Said that I do sometimes use it in a micro-benchmark just to convince myself we don't lose much performance on the checks. Usually it turns out fine, I'm happy and move on. But I guess there's some value in being able to elide a lot of checks just to see how much of a difference it does. And if there's a big difference then I'd try to optimise the program and elide unnecessary checks myself. Clearly -Ounchecked should never be used in any real code but I find having a baseline when optimising performance very helpful and -Ounchecked sometimes seemed like a cheap, automatic baseline for some code ;).

And lastly I always thought having it as an 'optimisation' is a misnomer, it's not an optimisation as it clearly changes the semantics of the program quite a bit. I thought '-unsafe-remove-checks' or something describes it better, a bit like '-assume-single-threaded'. But probably the 'no checks' mode adds too much complexity to just keep it around for a questionable way to do performance baselines.

···

On 2 Nov 2017, at 9:52 am, Erik Eckstein via swift-dev <swift-dev@swift.org> wrote:

Hi,

I’d like to propose to deprecate the -Ounchecked swift optimization mode.

The -Ounchecked mode actually contradicts one of the main goals of swift: to be a safe language.
In the past we didn’t see lot of significant performance differences compared to -O (there were some improvements but also some regressions).
Also, we want to reduce the effort of maintaining too many different optimization modes, especially because we recently added -Osize.

Deprecating would mean that we map -Ounchecked to -O.

If you have any comments or concerns, please let me know

Thanks,
Erik

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

3

I am +1 in general, but I do feel there is a legitimate need for this for a very very small subset of code. It would feel unfortunate to need to drop to C for that — would an equivalent attribute be an alternative?

- Daniel

···

On Nov 2, 2017, at 9:52 AM, Erik Eckstein via swift-dev <swift-dev@swift.org> wrote:

Hi,

I’d like to propose to deprecate the -Ounchecked swift optimization mode.

The -Ounchecked mode actually contradicts one of the main goals of swift: to be a safe language.
In the past we didn’t see lot of significant performance differences compared to -O (there were some improvements but also some regressions).
Also, we want to reduce the effort of maintaining too many different optimization modes, especially because we recently added -Osize.

Deprecating would mean that we map -Ounchecked to -O.

If you have any comments or concerns, please let me know

Thanks,
Erik

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

4

What’s the motivation for this? What problem does it solve?

Swift isn’t a "strict safety at all costs” language. It is a pragmatic language which aims to give people tools to solve problems. One of the nice things about -Ounchecked is that it provides an easy way to get a data point about the cost of runtime checks.

-Chris

···

On Nov 2, 2017, at 9:52 AM, Erik Eckstein via swift-dev <swift-dev@swift.org> wrote:

Hi,

I’d like to propose to deprecate the -Ounchecked swift optimization mode.

The -Ounchecked mode actually contradicts one of the main goals of swift: to be a safe language.
In the past we didn’t see lot of significant performance differences compared to -O (there were some improvements but also some regressions).
Also, we want to reduce the effort of maintaining too many different optimization modes, especially because we recently added -Osize.

Deprecating would mean that we map -Ounchecked to -O.

If you have any comments or concerns, please let me know

2 Likes
5

Definitely a +1 from me, a haven't recently seen much of a difference either.

Said that I do sometimes use it in a micro-benchmark just to convince myself we don't lose much performance on the checks. Usually it turns out fine, I'm happy and move on. But I guess there's some value in being able to elide a lot of checks just to see how much of a difference it does. And if there's a big difference then I'd try to optimise the program and elide unnecessary checks myself. Clearly -Ounchecked should never be used in any real code but I find having a baseline when optimising performance very helpful and -Ounchecked sometimes seemed like a cheap, automatic baseline for some code ;).

And lastly I always thought having it as an 'optimisation' is a misnomer, it's not an optimisation as it clearly changes the semantics of the program quite a bit. I thought '-unsafe-remove-checks' or something describes it better, a bit like '-assume-single-threaded’.

I like that idea. We could add such an option.

Daniel, I think that’s also what you were asking for.

···

On Nov 2, 2017, at 10:51 AM, Johannes Weiß <johannesweiss@apple.com> wrote:

But probably the 'no checks' mode adds too much complexity to just keep it around for a questionable way to do performance baselines.

On 2 Nov 2017, at 9:52 am, Erik Eckstein via swift-dev <swift-dev@swift.org> wrote:

Hi,

I’d like to propose to deprecate the -Ounchecked swift optimization mode.

The -Ounchecked mode actually contradicts one of the main goals of swift: to be a safe language.
In the past we didn’t see lot of significant performance differences compared to -O (there were some improvements but also some regressions).
Also, we want to reduce the effort of maintaining too many different optimization modes, especially because we recently added -Osize.

Deprecating would mean that we map -Ounchecked to -O.

If you have any comments or concerns, please let me know

Thanks,
Erik

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

6

Hi,

I’d like to propose to deprecate the -Ounchecked swift optimization mode.

The -Ounchecked mode actually contradicts one of the main goals of swift: to be a safe language.
In the past we didn’t see lot of significant performance differences compared to -O (there were some improvements but also some regressions).
Also, we want to reduce the effort of maintaining too many different optimization modes, especially because we recently added -Osize.

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.

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.

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 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 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).

···

On Nov 2, 2017, at 8:50 PM, Chris Lattner <clattner@nondot.org> wrote:

On Nov 2, 2017, at 9:52 AM, Erik Eckstein via swift-dev <swift-dev@swift.org> wrote:

Swift isn’t a "strict safety at all costs” language. It is a pragmatic language which aims to give people tools to solve problems. One of the nice things about -Ounchecked is that it provides an easy way to get a data point about the cost of runtime checks.

-Chris

7

Definitely a +1 from me, a haven't recently seen much of a difference either.

Said that I do sometimes use it in a micro-benchmark just to convince myself we don't lose much performance on the checks. Usually it turns out fine, I'm happy and move on. But I guess there's some value in being able to elide a lot of checks just to see how much of a difference it does. And if there's a big difference then I'd try to optimise the program and elide unnecessary checks myself. Clearly -Ounchecked should never be used in any real code but I find having a baseline when optimising performance very helpful and -Ounchecked sometimes seemed like a cheap, automatic baseline for some code ;).

And lastly I always thought having it as an 'optimisation' is a misnomer, it's not an optimisation as it clearly changes the semantics of the program quite a bit. I thought '-unsafe-remove-checks' or something describes it better, a bit like '-assume-single-threaded’.

I like that idea. We could add such an option.

awesome, that's be a +:100: from me then :slightly_smiling_face:

···

On 2 Nov 2017, at 1:33 pm, Erik Eckstein <eeckstein@apple.com> wrote:

On Nov 2, 2017, at 10:51 AM, Johannes Weiß <johannesweiss@apple.com> wrote:

Daniel, I think that’s also what you were asking for.

But probably the 'no checks' mode adds too much complexity to just keep it around for a questionable way to do performance baselines.

On 2 Nov 2017, at 9:52 am, Erik Eckstein via swift-dev <swift-dev@swift.org> wrote:

Hi,

I’d like to propose to deprecate the -Ounchecked swift optimization mode.

The -Ounchecked mode actually contradicts one of the main goals of swift: to be a safe language.
In the past we didn’t see lot of significant performance differences compared to -O (there were some improvements but also some regressions).
Also, we want to reduce the effort of maintaining too many different optimization modes, especially because we recently added -Osize.

Deprecating would mean that we map -Ounchecked to -O.

If you have any comments or concerns, please let me know

Thanks,
Erik

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

8

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

···

On Nov 3, 2017, at 8:31 AM, Erik Eckstein via swift-dev <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.

9

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

···

On Nov 3, 2017, at 8:31 AM, Erik Eckstein via swift-dev <swift-dev@swift.org> wrote:

1 Like
10

Definitely a +1 from me, a haven't recently seen much of a difference either.

Said that I do sometimes use it in a micro-benchmark just to convince myself we don't lose much performance on the checks. Usually it turns out fine, I'm happy and move on. But I guess there's some value in being able to elide a lot of checks just to see how much of a difference it does. And if there's a big difference then I'd try to optimise the program and elide unnecessary checks myself. Clearly -Ounchecked should never be used in any real code but I find having a baseline when optimising performance very helpful and -Ounchecked sometimes seemed like a cheap, automatic baseline for some code ;).

And lastly I always thought having it as an 'optimisation' is a misnomer, it's not an optimisation as it clearly changes the semantics of the program quite a bit. I thought '-unsafe-remove-checks' or something describes it better, a bit like '-assume-single-threaded’.

I like that idea. We could add such an option.

awesome, that's be a +:100: from me then :slightly_smiling_face:

Yeah, if the proposal is really just to provide a separate option for turning off safety checks instead of conflating it into the -O option, that seems totally unobjectionable.

John.

···

On Nov 2, 2017, at 4:35 PM, Johannes Weiß via swift-dev <swift-dev@swift.org> wrote:

On 2 Nov 2017, at 1:33 pm, Erik Eckstein <eeckstein@apple.com> wrote:

On Nov 2, 2017, at 10:51 AM, Johannes Weiß <johannesweiss@apple.com> wrote:

Daniel, I think that’s also what you were asking for.

But probably the 'no checks' mode adds too much complexity to just keep it around for a questionable way to do performance baselines.

On 2 Nov 2017, at 9:52 am, Erik Eckstein via swift-dev <swift-dev@swift.org> wrote:

Hi,

I’d like to propose to deprecate the -Ounchecked swift optimization mode.

The -Ounchecked mode actually contradicts one of the main goals of swift: to be a safe language.
In the past we didn’t see lot of significant performance differences compared to -O (there were some improvements but also some regressions).
Also, we want to reduce the effort of maintaining too many different optimization modes, especially because we recently added -Osize.

Deprecating would mean that we map -Ounchecked to -O.

If you have any comments or concerns, please let me know

Thanks,
Erik

_______________________________________________
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

11

A -1 from me to deprecating the mode. I’ve been using Swift in high-performance situations such as in a game engine, where in particular thing like integer overflow checks become a measurable cost in tight inner loops. Currently I can’t use Array in many places due to ownership issues and retain/release costs, but once that hopefully becomes feasible I’d also definitely want the option to elide e.g. range checks.

I’m aware there are alternatives to e.g. add without overflow checking with &+ (which I use in some cases to make debug mode usable), but in general it’s very useful to be able to test with these checks in debug mode and then have them stripped in a release build once you’re reasonably confident they’re safe.

As a side note, if you’re only discussing renaming, I think it’s already exposed as two separate options in Xcode: you have optimisation level (mapping to -Onone, -O, -O,-wmo) and a separate ‘Disable Safety Checks’ option. Mapping the compiler flags to match would I think make sense.

I’m curious as to when you see performance regressions with -Ounchecked. Does it limit the ability of the compiler to make some optimisations?

Thomas

···

On 3/11/2017, at 9:35 AM, Johannes Weiß via swift-dev <swift-dev@swift.org> wrote:

On 2 Nov 2017, at 1:33 pm, Erik Eckstein <eeckstein@apple.com> wrote:

On Nov 2, 2017, at 10:51 AM, Johannes Weiß <johannesweiss@apple.com> wrote:

Definitely a +1 from me, a haven't recently seen much of a difference either.

Said that I do sometimes use it in a micro-benchmark just to convince myself we don't lose much performance on the checks. Usually it turns out fine, I'm happy and move on. But I guess there's some value in being able to elide a lot of checks just to see how much of a difference it does. And if there's a big difference then I'd try to optimise the program and elide unnecessary checks myself. Clearly -Ounchecked should never be used in any real code but I find having a baseline when optimising performance very helpful and -Ounchecked sometimes seemed like a cheap, automatic baseline for some code ;).

And lastly I always thought having it as an 'optimisation' is a misnomer, it's not an optimisation as it clearly changes the semantics of the program quite a bit. I thought '-unsafe-remove-checks' or something describes it better, a bit like '-assume-single-threaded’.

I like that idea. We could add such an option.

awesome, that's be a +:100: from me then :slightly_smiling_face:

Daniel, I think that’s also what you were asking for.

But probably the 'no checks' mode adds too much complexity to just keep it around for a questionable way to do performance baselines.

On 2 Nov 2017, at 9:52 am, Erik Eckstein via swift-dev <swift-dev@swift.org> wrote:

Hi,

I’d like to propose to deprecate the -Ounchecked swift optimization mode.

The -Ounchecked mode actually contradicts one of the main goals of swift: to be a safe language.
In the past we didn’t see lot of significant performance differences compared to -O (there were some improvements but also some regressions).
Also, we want to reduce the effort of maintaining too many different optimization modes, especially because we recently added -Osize.

Deprecating would mean that we map -Ounchecked to -O.

If you have any comments or concerns, please let me know

Thanks,
Erik

_______________________________________________
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

1 Like
12

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.

Slava

···

On Nov 3, 2017, at 8:57 PM, Chris Lattner via swift-dev <swift-dev@swift.org> wrote:

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.

13

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.

-Andy

···

On Nov 3, 2017, at 12:45 PM, Slava Pestov via swift-dev <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

14

A -1 from me to deprecating the mode. I’ve been using Swift in high-performance situations such as in a game engine, where in particular thing like integer overflow checks become a measurable cost in tight inner loops. Currently I can’t use Array in many places due to ownership issues and retain/release costs, but once that hopefully becomes feasible I’d also definitely want the option to elide e.g. range checks.

I’m aware there are alternatives to e.g. add without overflow checking with &+ (which I use in some cases to make debug mode usable), but in general it’s very useful to be able to test with these checks in debug mode and then have them stripped in a release build once you’re reasonably confident they’re safe.

As a side note, if you’re only discussing renaming, I think it’s already exposed as two separate options in Xcode: you have optimisation level (mapping to -Onone, -O, -O,-wmo) and a separate ‘Disable Safety Checks’ option. Mapping the compiler flags to match would I think make sense.

As I said, I like the idea from Johannes to add -unsafe-remove-checks, similar to -assume-single-threaded. I hope that’s ok with you.

I’m curious as to when you see performance regressions with -Ounchecked. Does it limit the ability of the compiler to make some optimisations?

We didn’t actually investigate those regressions. But whenever the optimizer runs a different path it can happen that performance also regresses, even when it’s unexpected. For example, inlining decisions may change, which can have a big impact in both directions.

···

On Nov 2, 2017, at 1:56 PM, Thomas Roughton via swift-dev <swift-dev@swift.org> wrote:

Thomas

On 3/11/2017, at 9:35 AM, Johannes Weiß via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

On 2 Nov 2017, at 1:33 pm, Erik Eckstein <eeckstein@apple.com <mailto:eeckstein@apple.com>> wrote:

On Nov 2, 2017, at 10:51 AM, Johannes Weiß <johannesweiss@apple.com <mailto:johannesweiss@apple.com>> wrote:

Definitely a +1 from me, a haven't recently seen much of a difference either.

Said that I do sometimes use it in a micro-benchmark just to convince myself we don't lose much performance on the checks. Usually it turns out fine, I'm happy and move on. But I guess there's some value in being able to elide a lot of checks just to see how much of a difference it does. And if there's a big difference then I'd try to optimise the program and elide unnecessary checks myself. Clearly -Ounchecked should never be used in any real code but I find having a baseline when optimising performance very helpful and -Ounchecked sometimes seemed like a cheap, automatic baseline for some code ;).

And lastly I always thought having it as an 'optimisation' is a misnomer, it's not an optimisation as it clearly changes the semantics of the program quite a bit. I thought '-unsafe-remove-checks' or something describes it better, a bit like '-assume-single-threaded’.

I like that idea. We could add such an option.

awesome, that's be a +:100: from me then :slightly_smiling_face:

Daniel, I think that’s also what you were asking for.

But probably the 'no checks' mode adds too much complexity to just keep it around for a questionable way to do performance baselines.

On 2 Nov 2017, at 9:52 am, Erik Eckstein via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

Hi,

I’d like to propose to deprecate the -Ounchecked swift optimization mode.

The -Ounchecked mode actually contradicts one of the main goals of swift: to be a safe language.
In the past we didn’t see lot of significant performance differences compared to -O (there were some improvements but also some regressions).
Also, we want to reduce the effort of maintaining too many different optimization modes, especially because we recently added -Osize.

Deprecating would mean that we map -Ounchecked to -O.

If you have any comments or concerns, please let me know

Thanks,
Erik

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

_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto: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

15

I don’t think there is an official policy, but IMO, all major new user visible features are in scope for evolution.

-Chris

···

On Nov 3, 2017, at 10:23 PM, Slava Pestov via swift-dev <swift-dev@swift.org> wrote:

On Nov 3, 2017, at 8:57 PM, Chris Lattner via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

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.

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.

16

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.

···

On Nov 5, 2017, at 4:05 PM, Andrew Trick <atrick@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:

-Andy

17

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.

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).
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.

But of course, we should discuss Ounchecked on swift-dev and that’s what we are doing now.

So far I got the feedback that some people still want to disable runtime checks and that’s perfectly fine.
There is no problem in keeping that code generation option in the compiler (and in fact it’s only a very small check in the optimizer) and we will test that it is functional correct. But we - the swift perf team - probably won’t have capacity to maintain performance tracking of this mode (e.g. checking and investigation of perf regressions). But hey, swift is an open source project and everyone who is interested can invest effort in this.

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.

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.

···

On Nov 3, 2017, at 10:51 PM, Chris Lattner via swift-dev <swift-dev@swift.org> wrote:

On Nov 3, 2017, at 10:23 PM, Slava Pestov via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

On Nov 3, 2017, at 8:57 PM, Chris Lattner via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

-Chris

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

18

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

···

On Nov 4, 2017, at 9:52 PM, Erik Eckstein <eeckstein@apple.com> wrote:

19

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.

···

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 <eeckstein@apple.com> wrote:

-Chris

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

20

I don’t think every flag needs to have a full evolution review cycle, but there should be at least a discussion about them, with a well marked subject line. If that discussion unearths controversy, then a more heavy weight process could be appropriate.

-Chris

···

On Nov 12, 2017, at 3:25 PM, Ted Kremenek via swift-dev <swift-dev@swift.org> wrote:

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.