or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:
Proposal link:
Reply text
Other replies
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at:
or, if you would like to keep your feedback private, directly to the
review manager. When replying, please try to keep the proposal link at the
top of the message:
The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:
- What is your evaluation of the proposal?
Excellent proposal overall. One particular point:
The name `--in-dir` doesn't mean anything to me. I foresee no way of
remembering which is `--chdir` and which is `--in-dir` other than
memorizing or looking it up. Intuitively, `--chdir` should mean the same
thing for each command (i.e. it should run before any other operation), so
I agree with the currently proposed design in that respect. The other
option could use a clearer name such as `--chdir-before-run`.
- Is the problem being addressed significant enough to warrant a
change to Swift?
An additive change, good net benefit.
- Does this proposal fit well with the feel and direction of Swift?
Yes.
- If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
Yes, it compares well.
- How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
A reasonably thorough reflection on the proposal.
···
On Mon, May 15, 2017 at 7:09 PM, Daniel Dunbar via swift-evolution < swift-evolution@swift.org> wrote:
It's not quite clear if `swift run --configuration release` runs the release build, but I'll assume it's true.
The considered alternative of symlinking to the latest build folder looks like an opportunity for bugs, as most stateful command-line interfaces: I'm not in favor for it.
Is the problem being addressed significant enough to warrant a change to Swift?
Yes, since the inner layout of the build folder is about to depend on the platform.
Does this proposal fit well with the feel and direction of Swift?
Sure
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
`swift run` has a taste of scripting language :-)
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
A read of the proposal.
Gwendal Roué
···
Le 16 mai 2017 à 02:09, Daniel Dunbar via swift-evolution <swift-evolution@swift.org> a écrit :
or, if you would like to keep your feedback private, directly to the
review manager. When replying, please try to keep the proposal link at the
top of the message:
The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:
- What is your evaluation of the proposal?
- Is the problem being addressed significant enough to warrant a
change to Swift?
- Does this proposal fit well with the feel and direction of Swift?
- If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
- How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
More information about the Swift evolution process is available at:
Excellent, except that `--chdir` and `--in-dir` are confusing. Why not use a long, clear name, just like `—enable-prefetching`? Consider `—working-dir` & `—preexec-working-dir`.
Is the problem being addressed significant enough to warrant a change to Swift?
Yes, esp when executables go into platform subfolders in Swift 4.
Does this proposal fit well with the feel and direction of Swift?
Yes.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Compares well. It’s very easy to use.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
A reasonably thorough read.
-Richard
···
On May 16, 2017, at 08:09, Daniel Dunbar via swift-evolution <swift-evolution@swift.org> wrote:
Hello Swift community,
The review of SE-0179: Swift `run` Command begins now and runs through May 25th, 2017.
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:
Proposal link:
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at:
It's not quite clear if `swift run --configuration release` runs the release build, but I'll assume it's true.
It’s true. Same behaviour as with swift test.
···
On 16 May 2017, at 14:32, Gwendal Roué via swift-evolution <swift-evolution@swift.org> wrote:
Le 16 mai 2017 à 02:09, Daniel Dunbar via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :
The considered alternative of symlinking to the latest build folder looks like an opportunity for bugs, as most stateful command-line interfaces: I'm not in favor for it.
Is the problem being addressed significant enough to warrant a change to Swift?
Yes, since the inner layout of the build folder is about to depend on the platform.
Does this proposal fit well with the feel and direction of Swift?
Sure
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
`swift run` has a taste of scripting language :-)
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
That would be my one bit of feedback as well. The names of these two parameters aren’t descriptive.
My suggestions would be:
--working-directory, -w Change working directory before any other operation
--run-directory, -r Change working directory before running the executable
I don’t believe there’s any reason to shorten or truncate the full parameters if you’re going to offer a single-character alias for them.
Otherwise, top proposal! 5 stars, would review again ;)
I’m +1 for SE-0179.
-t
···
On 17 May 2017, at 20:32, Richard Wei via swift-evolution <swift-evolution@swift.org> wrote:
Excellent, except that `--chdir` and `--in-dir` are confusing. Why not use a long, clear name, just like `—enable-prefetching`? Consider `—working-dir` & `—preexec-working-dir`
Same comments as Tony and Richard, I'm definitely +1 on the proposal, but I
find the directory-related flags confusingly named.
I think Tony's suggestion is interesting, but `-working-directory` is still
confusing, it could fit both uses, so maybe instead something like:
-build-directory : change before any operation (assuming the only
operations besides running the executable is to build it?)
-run-directory : working directory to run the executable
However, I understand that -chdir is already supported by existing commands
to change the working directory before any other operation, so maybe just
rename -in-dir to -run-directory would make sense. Or use the directory
provided to -chdir as both the build and run directories and drop the
-in-dir flag (after all, this is a convenience operation that combines
build and run by default, you can always build separately, then run with
-skip-build).
Thinking out loud a bit, but the basic idea is that those 2 flags are
confusing, but the rest looks good to me.
Martin
···
On Wed, May 17, 2017 at 08:07 Tony Arnold via swift-evolution < swift-evolution@swift.org> wrote:
> On 17 May 2017, at 20:32, Richard Wei via swift-evolution < > swift-evolution@swift.org> wrote:
>
> Excellent, except that `--chdir` and `--in-dir` are confusing. Why not
use a long, clear name, just like `—enable-prefetching`? Consider
`—working-dir` & `—preexec-working-dir`
That would be my one bit of feedback as well. The names of these two
parameters aren’t descriptive.
My suggestions would be:
--working-directory, -w Change working directory before any other
operation
--run-directory, -r Change working directory before running
the executable
I don’t believe there’s any reason to shorten or truncate the full
parameters if you’re going to offer a single-character alias for them.
Otherwise, top proposal! 5 stars, would review again ;)