[Accepted with Revision] SE-0179 Swift run Command


(Daniel Dunbar) #1

The review of SE-0179 "Swift run Command" ran from May 15...24, 2017. The proposal has been accepted with revision for Swift 4.

There was unanimous support for the proposal in general, but there was discussion on three major points:
1. The utility of having both "run -- ..." and "run command arg1 arg2" forms.
2. Whether to build by default.
3. The confusion of having two commands which "change the working directory'.

1. The `--` command syntax.

We decided we will not support the:
  swift run -- arg1 arg2 arg3
syntax, for packages with only one executable, because we felt it was not sufficiently useful versus spelling the command name, and we didn't want to unnecessarily have two ways to do the same thing. This behavior would be additive if it proved to be worth adding down the road.

We will support the no argument `swift run` form in the proposal, since it is unambiguous.

2. Whether to build by default.

This behavior is consistent with our existing behavior for `swift test`, and so we believe this is the correct behavior for this proposal.

3. The confusion over the `--chdir` and `--in-dir` arguments.

We agreed with the feedback that this was confusing, and so decided to:
* Rename the existing `--chdir` argument to `--package-path` and change it to simply define the package to work on instead of as a side effect of changing directories. We chose --package-path over --package to leave room for `--package <NAME>` syntax in the future, should we have an index. We will make this change and deprecate `--chdir` in Swift 4, and remove it at a later date.
* Remove the `--in-dir` argument, and instead leave it up to commands themselves to manage interaction with the working directory.
* Explicitly specify the behavior of `swift run` to always execute the command in the directory from with `swift run` was run.

In combination, these choices allow `swift run foo ...` to generally behave as it would if the package's products had been built, installed, and run via the shell normally. We believe this allows `swift run ...` to integrate with the shell as naturally as possible.

Thank you to everyone who participated!

Daniel Dunbar
Review Manager