Re: [swift-evolution] [swift-build-dev] [swiftpm] Add proposal for C language support

> On Jan 3, 2016, at 6:34 AM, Maury Markowitz via swift-evolution > wrote: > >> On Jan 2, 2016, at 9:00 AM, Daniel Dunbar via swift-build-dev >> wrote: >> >> Happy 2016! >> >> I am working on an initial proposal for adding support for C

[swift-evolution] [swiftpm] Add proposal for C language support

Happy 2016! I am working on an initial proposal for adding support for C language targets to the Swift package manager, and am interested in feedback: https://github.com/ddunbar/swift-evolution/blob/master/proposals/-swiftpm-c-language-targets.md Some TL;DR: - The proposal defines a

Re: [swift-evolution] Draft Proposal SwiftPM System Module Search Paths

I don't see that information in the man page (also, I am not familiar enough with pkg-config to know how results described in that man page translate to other systems). Specifically, that man page does not seem to document where on disk the .pc files live. How are we going to know that? For

Re: [swift-evolution] Draft Proposal SwiftPM System Module Search Paths

> On Apr 6, 2016, at 11:11 AM, Max Howell wrote: > >> I don't see that information in the man page (also, I am not familiar enough >> with pkg-config to know how results described in that man page translate to >> other systems). >> >> Specifically, that man page does

Re: [swift-evolution] [Review] SE-0063: SwiftPM System Module Search Paths

> On Apr 7, 2016, at 1:14 PM, Anders Bertelrud via swift-evolution > wrote: > > 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,

Re: [swift-evolution] Proposal Discussion Thread: SwiftPM: Locking and Overriding Dependencies

My thoughts on this proposal: 1. I agree with some of the other comments that I would prefer the version file be adjacent to "Package.swift". When the Packages directory isn't being checked in, I really would like to think of it as an "implementation detail" and not embed functionality inside

Re: [swift-evolution] Proposal Discussion Thread: SwiftPM: Locking and Overriding Dependencies

> On Mar 21, 2016, at 4:05 PM, Max Howell wrote: > >> 2. I like VersionLocks.json well enough, but would like to see a discussion >> about possible alternatives. My personal proposal (in line with #1) is to >> use "PackageVersions.json" which has a nice agreement with

Re: [swift-evolution] Draft Proposal SwiftPM System Module Search Paths

Hi Max, The proposal refers to "the pkg-config specification", can you add a link to that? In particular, I am curious how SwiftPM will know where to look for those files. - Daniel > On Mar 31, 2016, at 4:04 PM, Max Howell via swift-evolution > wrote: > > I have

[swift-evolution] RFC: Swift Package Manager -- Editable Packages Proposal

I am proposing we change the behavior for iterative development of a group of packages. In particular, we will change the default location to which package dependency sources are cloned, the package managers behavior around those sources, and add a new feature for allowing iterative

Re: [swift-evolution] [Review] SE-0085: Package Manager Command Names

an alias as something that can be added later if it proves to be the right thing to do. Thanks! - Daniel > On May 9, 2016, at 3:05 PM, Daniel Dunbar via swift-evolution > <swift-evolution@swift.org> wrote: > > Hello Swift community, > > The review of "SE-0085: Package

Re: [swift-evolution] [swift-build-dev] [Review] SE-0085: Package Manager Command Names

> On May 10, 2016, at 12:42 AM, Rob Allen via swift-build-dev > wrote: > > >> On 9 May 2016, at 23:05, Daniel Dunbar via swift-build-dev >> wrote: >> >> Hello Swift community, >> >> The review of "SE-0085: Package Manager Command

[swift-evolution] [Review] SE-0085: Package Manager Command Names

Hello Swift community, The review of "SE-0085: Package Manager Command Names" begins now and runs through May 12. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0085-package-manager-command-name.md Reviews are an important part of the

[swift-evolution] [Accepted] SE-0129: Package Manager Test Naming Conventions

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0129-package-manager-test-naming-conventions.md The review of "SE-0129: Package Manager Test Naming Conventions" ran from Active review July 22...26. The proposal has been *accepted*. There was relatively little

Re: [swift-evolution] [swift-build-dev] Proposal: SwiftPM Target Access Control

> On Jul 11, 2016, at 8:30 AM, Ankit Agarwal via swift-build-dev > wrote: > > > 1. One major reason for wanting control over which targets are exported are > so packages can control which parts of their API is supported for external > use. This is very important

Re: [swift-evolution] [swift-build-dev] Proposal: SwiftPM Target Access Control

> On Jul 13, 2016, at 1:56 AM, Honza Dvorsky wrote: > > Very happy to see this proposal, thanks Ankit for pushing it forward! I can't > wait to be able to hide many example executables in my packages, as I've been > getting a steady stream of complaints from people being

Re: [swift-evolution] [swift-build-dev] Proposal: SwiftPM Target Access Control

Thanks for writing this up, I definitely want us to figure out how to handle this problem. One thing I would like to see addressed alongside this is the ability to specify the dependency on a SwiftPM target level, since that is usually where the dependency lies (one target imports another) and

Re: [swift-evolution] [swift-build-dev] Proposal: SwiftPM Target Access Control

On Thu, Jul 7, 2016 at 2:02 PM, Kostiantyn Koval via swift-build-dev < swift-build-...@swift.org> wrote: > Hi > Thanks for the proposal, looks very nice. > > The *Package.swift* manifest files is very string typed already, (package > name, url, target names, etc) and and think that is ok in our

Re: [swift-evolution] [swift-build-dev] Proposal: SwiftPM Target Access Control

Some minor points: 1. One major reason for wanting control over which targets are exported are so packages can control which parts of their API is supported for external use. This is very important to large projects undergoing active development while also trying to support a well-defined,

Re: [swift-evolution] [Review] SE-0135: Package Manager Support for Differentiating Packages by Swift version

> On Aug 4, 2016, at 9:16 AM, Rob Allen <r...@akrabat.com> wrote: > > I appreciate that I'm late on this, but I'm on vacation. Thanks for the response, I'm glad to be getting some additional feedback. >> On 29 Jul 2016, at 20:36, Daniel Dunbar via swift-evolution

[swift-evolution] [Accepted] SE-0135: Package Manager Support for Differentiating Packages by Swift version

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0135-package-manager-support-for-differentiating-packages-by-swift-version.md The review of "SE-0135: Package Manager Support for Differentiating Packages by Swift version" ran from Active review July 29...August 03.

[swift-evolution] [Review] SE-0135: Package Manager Support for Differentiating Packages by Swift version

Hello Swift community, The review of "SE-0135: Package Manager Support for Differentiating Packages by Swift version" begins now and runs through August 3rd. The proposal is available here:

[swift-evolution] [Accepted] SE-0149: Package Manager Support for Top of Tree development

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0149-package-manager-top-of-tree.md The review of SE-0149 "Package Manager Support for Top of Tree development" ran from January 24…31. Feedback was positive, and the proposal is accepted for Swift 4. Thanks to

[swift-evolution] [Accepted] SE-0150: Package Manager Support for branches

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0150-package-manager-branch-support.md The review of SE-0150 "Package Manager Support for branches" ran from January 24…31. Feedback was positive, and the proposal is accepted for Swift 4. Thanks to everyone who

Re: [swift-evolution] [swift-build-dev] Package manager support for versioning (both language and tools)

> On Feb 6, 2017, at 4:18 PM, Xiaodi Wu via swift-evolution > wrote: > > I think I agree with Rick. I see no benefit to making it look like this line > is Swift when it's really not parsed as such. Like a doctype in HTML or a > shebang line in Python, a special

Re: [swift-evolution] [swift-build-dev] Draft SwiftPM proposal: Multi-package repositories

can test them together on CI. > https://github.com/exercism/xswift/commit/4935b94c78a69f88b42c7a518c16e0c8b4f6fe8d#diff-37ca2dd15ca0f6b1b49e78db084ef5b9R21 > > <https://github.com/exercism/xswift/commit/4935b94c78a69f88b42c7a518c16e0c8b4f6fe8d#diff-37ca2dd15ca0f6b1b49e78db084ef5b9R21> &

Re: [swift-evolution] [swift-build-dev] [Review] SE-0149 Package Manager Support for Top of Tree development

I am reposting this since the URLs were mangled in the original email. Hello Swift community, The review of SE-0149 “ Package Manager Support for Top of Tree development" begins now and runs through January 31, 2017. The proposal is available here:

[swift-evolution] [Review] SE-0150 Package Manager Support for branches

Hello Swift community, The review of SE-0150 “ Package Manager Support for branches" begins now and runs through January 31, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0150-package-manager-branch-support.md Reviews are an important

Re: [swift-evolution] [swift-build-dev] SwiftPM C++ Support

Hi Harlan, Can you describe more about exactly what distinct problems you are running into? Thanks! - Daniel On Mon, Jan 16, 2017 at 10:54 AM, Ankit Agarwal via swift-build-dev < swift-build-...@swift.org> wrote: > + swift-build-dev > > On Tue, Jan 17, 2017 at 12:03 AM, Harlan Haskins via

[swift-evolution] Swift Package Manager 3.0 Project Status

Hi everyone, The package manager was a brand new project released with open source Swift, and we have made significant progress as part of Swift 3.0. Starting from that humble beginning we now estimate there are around 3,500 Swift Packages on GitHub (*), with more and more showing up every

Re: [swift-evolution] [swift-build-dev] [Review] SE-0135: Package Manager Support for Differentiating Packages by Swift version

Hi Max, > On Aug 4, 2016, at 6:46 AM, Max Desiatov wrote: > > Hi Daniel, > > I hope this proposal really is still in active review, as it is marked as > such in the swift-evolution Git repository. It was supposed to close yesterday, but I haven't gotten to the

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Manifest API Redesign

Oh, and to your later email: The reason why we wanted product type to use subclasses, and not a type field, is that we imagine product types growing to encompass other things for which it does not make sense to share the fields across all other products. Right now the Product type looks very

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Manifest API Redesign

> On Feb 28, 2017, at 12:28 AM, Jens Nerup wrote: > > Hello Daniel, > > In general I’m really happy with the changes in the proposal and especially > after you have incorporated the comments from David (Thanks David). In the > proposal it is stated that the exclude section

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Manifest API Redesign

> On Feb 27, 2017, at 10:24 PM, David Hart wrote: > > > > On 28 Feb 2017, at 01:50, Daniel Dunbar > wrote: > >> Hi David, >> >> We discussed the leading-dot & capitalization issue today again... this was >>

Re: [swift-evolution] Swift Package Manager 3.0 Project Status

e the near term plans–if there are any–for supporting iOS? I made the > mistake of assuming support was a couple months away at most when the package > manager was announced. I plan to port my iOS/Mac frameworks over as soon as I > can. > > TJ > >> On Wed, Aug 17, 2

Re: [swift-evolution] [Review] SE-0145: Package Manager Version Pinning

> On Nov 4, 2016, at 5:28 AM, Max Desiatov via swift-evolution > wrote: > > Hi all, > >> On 31 Oct 2016, at 21:23, Anders Bertelrud via swift-evolution >> > wrote: >> >> * What is your evaluation of

Re: [swift-evolution] [Review] SE-0145: Package Manager Version Pinning

Thanks to everyone who participated in this review! Based on the pretty universal negative feedback, we are going to reject this proposal as is, and take it back for another round of revisions. Our revised plan is: 1. To introduce an "autopin" behavior to cover the problem Paul outlined where

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

Ok, great! We will discuss this some more and see what we can come up with. - Daniel > On Oct 14, 2016, at 2:18 PM, orta therox wrote: > > Same, yeah  > >> On 14 Oct 2016, at 21:21, Eloy Durán via swift-build-dev >> wrote: >> >>> 5. Given

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

I'm replying here as a proxy for a bunch of other messages, since it is the latest one when I started typing. :) > On Oct 14, 2016, at 12:40 PM, Ryan Lovelett > wrote: > >> I particularly like Yehuda Katz's explanation on why it works this way: >>

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

> On Oct 14, 2016, at 4:02 PM, Paul Cantrell wrote: > > Sorry for the late arrival to this thread. Comments below… > >> On Oct 14, 2016, at 3:09 PM, Daniel Dunbar via swift-build-dev >> wrote: >> >> What this proposal about is in one sense

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

> On Oct 14, 2016, at 4:15 PM, Johannes Weiß wrote: > > Hey, > >> [...] >> I see it as my responsibility to know exactly what code I’m pulling into my >> package. In my view, it’s absolutely unsafe to trust other people’s code. >> Even when they mean no harm,

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

> On Oct 14, 2016, at 4:51 PM, Paul Cantrell via swift-evolution > wrote: > > > >> On Oct 14, 2016, at 6:34 PM, Eloy Durán wrote: >> >>> I’m puzzled. If a package’s pinning does not affect any other package that >>> uses it, why should

[swift-evolution] Draft SwiftPM proposal: Multi-package repositories

Hi all, I'm reposting a request for feedback on my proposal for extending SwiftPM to support multiple packages inside one repository (i.e. "monorepo" support, although it is a misnomer in this use case).

Re: [swift-evolution] [Review] SE-0145: Package Manager Version Pinning (Revised)

> On Nov 23, 2016, at 3:03 PM, Martin Waitz via swift-evolution > wrote: > >> The review of "SE-0145: Package Manager Version Pinning" begins again after >> revisions, starting now and running through November 28th. The proposal is >> available here: >> >>

Re: [swift-evolution] [Review] SE-0145: Package Manager Version Pinning

I have implemented the revisions to SE-0145 to support automatic pinning. The approach we took was to leave much of the existing behaviors, but to support an "automatic pinning" mode which is then on by default. If anyone wants to provide early feedback, my draft is here:

[swift-evolution] [Review] SE-0146: Package Manager Product Definitions

Hello Swift community, The review of "SE-0146: Package Manager Product Definitions" begins now and runs through November 28th. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0146-package-manager-product-definitions.md Reviews are an

Re: [swift-evolution] [swift-build-dev] Draft SwiftPM proposal: Multi-package repositories

> On Nov 12, 2016, at 9:43 PM, Russ Bishop wrote: > > >> On Nov 12, 2016, at 1:02 PM, Daniel Dunbar via swift-build-dev >> wrote: >> >> Hi all, >> >> I'm reposting a request for feedback on my proposal for extending SwiftPM to >> support

Re: [swift-evolution] [swift-build-dev] Draft SwiftPM proposal: Multi-package repositories

le syntax. > > On a side note, do we really need a "subpackage" argument for the Package > initializer and not roll everything under "package"? How would this look? - Daniel > David. > > > On 13 Nov 2016, at 06:54, Daniel Dunbar via swift-evolution < &g

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

ementation of the mechanism on figuring out the right design for that. If we get a design for that, we will also probably use that to change the default policy here. Please take a look at the new proposal, and see what you think. Thanks, - Daniel > On Oct 14, 2016, at 4:42 PM, Daniel Dun

Re: [swift-evolution] Proposal: Package Manager Version Pinning

Hi Jay, > On Oct 16, 2016, at 7:14 PM, Jay Abbott wrote: > > > I like the core idea here, but I feel that it could potentially prevent teams > updating, through focus on other things and general laziness/ignorance to > what's going on with external dependencies. Although

Re: [swift-evolution] Proposal: Package Manager Version Pinning

> On Oct 14, 2016, at 10:03 AM, Max Desiatov via swift-evolution > wrote: > > The other point is that when working in a multi-language environment, having > conventions such as this broken causes additional mental burden. That is, > after working with

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

> On Oct 14, 2016, at 10:13 AM, orta therox wrote: > > Afraid it doesn’t convince me. Even if you have an index that has strict > semver adherence, the idea that you can trust people / machines to actually > understand whether something will break other people's build

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

> On Oct 14, 2016, at 9:35 AM, Daniel Duan wrote: > > The spelling nitpick should have been on GitHub in retrospect. I wrongly > assumed everyone know of our preference for dialect :) > > Point 1-7 are all concrete descriptions of features. That's probably why the > SHA

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

> On Oct 13, 2016, at 11:16 PM, Daniel Duan via swift-build-dev > wrote: > > This is a familiar feature among package managers and has been proven useful > in practice. Two points regarding the proposed text: > > 1. “honor” is mis-spelled in “weird queen’s

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

Hey Orta, Thanks for this feedback, this was one of the hotly debated points as you might imagine. Can you elaborate on exactly how you would prefer this to work? The way I see it, the only thing that this changes is that the initial package **author** who wants to be in this situation has

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

Hey Eloy, Same question as I sent to Orta, can you detail exactly what you would prefer to change? > On Oct 14, 2016, at 4:06 AM, Eloy Durán via swift-evolution > wrote: > > I cannot agree more with Orta. > > > It drives the user away from taking full advantage of

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

Can you check my reply to Eloy and see how it weighs with you? - Daniel > On Oct 14, 2016, at 9:33 AM, Max Desiatov via swift-build-dev > wrote: > > I also strongly agree with this, I'd prefer version pinning to happen by > default, rather than with explicit

Re: [swift-evolution] Proposal: Package Manager Version Pinning

Let's not change this thread into a discussion of English. :) - Daniel > On Oct 14, 2016, at 8:54 AM, Daniel Duan via swift-evolution > wrote: > > Fyi, not my idea: > https://github.com/apple/swift-evolution/commit/51d93875b25ba122a6417fdc5216ee94c6e7ee9e > >

Re: [swift-evolution] Proposal: Package Manager Version Pinning

> On Oct 14, 2016, at 9:43 AM, Alexis via swift-evolution > wrote: > > > >> On Oct 14, 2016, at 2:01 AM, Ankit Aggarwal via swift-evolution >> > wrote: >> >> Hi, >> >> We're proposing version pinning

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

> On Oct 14, 2016, at 10:39 AM, Max Desiatov wrote: > > Unfortunately, I'm not convinced that semantic versioning would help here. It > could have been different if any of the tools in Apple's ecosystem and other > ecosystems emphasized semantic versioning from the

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

> On Oct 14, 2016, at 10:37 AM, Eloy Duran wrote: > > Hey Daniel, > > Totally  I'm not sure what this is to. :) > I think you should pin by default, I wouldn't even provide some option to > disable it. Pin by default in the sense you are using it just means we

Re: [swift-evolution] Proposal: Package Manager Version Pinning

> On Oct 14, 2016, at 10:37 AM, Huon Wilson via swift-evolution > wrote: > > >> On Oct 14, 2016, at 09:43, Alexis via swift-evolution >> > wrote: >> >> A library shouldn’t pin its dependencies, while an

Re: [swift-evolution] Proposal: Package Manager Version Pinning

> On Oct 14, 2016, at 12:04 PM, Ryan Lovelett > wrote: > >> Whether "pinning" is the right word is a different debate, but when we view >> pinning as a workflow-focused feature, versus the specification in the >> manifest (which is the "requirement"), then I think

Re: [swift-evolution] [swift-build-dev] [Accepted] SE-0146: Package Manager Product Definitions

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0146-package-manager-product-definitions.md The review of "SE-0146: Package Manager Product Definitions" ran from November 18...28. The proposal has been *accepted*. The proposal received no feedback, but as the

Re: [swift-evolution] [Review] SE-0145: Package Manager Version Pinning (Revised)

> On Dec 5, 2016, at 8:09 PM, Paul Cantrell wrote: > > >> On Dec 2, 2016, at 11:11 AM, Daniel Dunbar > > wrote: >> >> >>> On Nov 28, 2016, at 8:25 PM, Paul Cantrell via swift-evolution >>>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0145: Package Manager Version Pinning (Revised)

> On Dec 1, 2016, at 1:42 PM, Alexis via swift-evolution > wrote: > > Haven’t had a chance to catch up on the latest discussion, but I just saw > that the Yarn developers posted an excellent piece on lockfiles this week: > >

Re: [swift-evolution] [swift-build-dev] [swift-evolution-announce] [Review] SE-0145: Package Manager Version Pinning (Revised)

> On Nov 28, 2016, at 9:44 AM, David Sweeris via swift-build-dev > wrote: > > > On Nov 19, 2016, at 23:48, Anders Bertelrud > wrote: > >> Hello Swift community, >> >> The review of "SE-0145: Package Manager Version

Re: [swift-evolution] [swift-build-dev] [Review] SE-0145: Package Manager Version Pinning (Revised)

Hi Alex, > On Nov 24, 2016, at 4:54 AM, Alex Blewitt via swift-build-dev > wrote: > > >> On 20 Nov 2016, at 05:48, Anders Bertelrud via swift-evolution >> > wrote: >> >> * What is your evaluation of

Re: [swift-evolution] [Review] SE-0145: Package Manager Version Pinning (Revised)

> On Nov 28, 2016, at 8:25 PM, Paul Cantrell via swift-evolution > wrote: > > Just a quick mini-review here; sorry, time pressure. > > This version of the proposal seems acceptable to me, though I have a nagging > feel that it’s more complex than it needs to be. I

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Manifest API Redesign

Hi David, We discussed the leading-dot & capitalization issue today again... this was already something we weren't really happy about, but had chosen to live with (using the "identity" rule to determine what was a type and what wasn't). However, as we talked it over more we: 1. Felt that for

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0181: Package Manager C/C++ Language Standard Support

A couple more points I skipped earlier... > On Jul 12, 2017, at 3:03 PM, Jordan Rose wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0181-package-manager-cpp-language-version.md > >

[swift-evolution] [Review] SE-0181: Package Manager C/C++ Language Standard Support

Hello Swift community, The review of SE-0181: Package Manager C/C++ Language Standard Support begins now and runs through July 14th, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0181-package-manager-cpp-language-version.md Reviews are

[swift-evolution] [Accepted with Revision] SE-0181: Package Manager C/C++ Language Standard Support

The review of SE-0181: Package Manager C/C++ Language Standard Support ran from July 11...14, 2017. The proposal has been accepted for Swift 4. There was support for the general feature, with some discussion of the spelling. We chose to accept the proposal mostly unmodified: 1. While we agreed

Re: [swift-evolution] [swift-build-dev] [swift-evolution-announce] [Review] SE-0181: Package Manager C/C++ Language Standard Support

Combo reply... > On Jul 12, 2017, at 3:58 PM, Chris Lattner via swift-build-dev > wrote: > >> >> On Jul 12, 2017, at 3:03 PM, Jordan Rose via swift-evolution >> > wrote: >> >> [Proposal: >>

Re: [swift-evolution] pitch: Unified libc import (again)

> On Aug 17, 2017, at 3:47 PM, Taylor Swift wrote: > > > > On Thu, Aug 17, 2017 at 3:50 PM, Daniel Dunbar > wrote: > > > On Aug 17, 2017, at 9:26 AM, Taylor Swift via swift-evolution > >

Re: [swift-evolution] [swift-build-dev] [Pitch] Swift run Command

Huge +1 from me, and for having it build by default. Building should be efficient & transparent to the user IMHO. On Mon, May 15, 2017 at 11:43 AM Robert Widmann via swift-build-dev < swift-build-...@swift.org> wrote: > +1. A very useful feature to have, indeed. > > ~Robert Widmann > > On May

[swift-evolution] [Review] SE-0179: Swift `run` Command

Hello Swift community, The review of SE-0179: Swift `run` Command begins now and runs through May 25th, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0179-swift-run-command.md

[swift-evolution] [Accepted with Revision] SE-0179 Swift run Command

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