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

[Daniel Dunbar via swift-evolution]

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 that many people agree there are two workflows (we ourselves had 
>>> talked about this a lot when writing the proposal, but didn't put it in), 
>>> we felt it makes sense to consider adding that as an explicit declaration 
>>> *somewhere*.
>>> 
>>> @Eloy, @Orta: Suppose we had a semantic notion of which packages were 
>>> intended to be "top-level" versus used as a dependency, and we chose our 
>>> defaults accordingly (in this case, we would orient workflows towards 
>>> pinning by default in the top-level case, in the used as a dependency case 
>>> we would orient away from it, e.g. warning you if you checked it in). What 
>>> would you think of such a design?
>> 
>> Oooh, I like it.
>> 
>> Even though I would probably still pin/lock personally, I think this default 
>> combined with the explicit declaration strikes a perfect balance in 
>> trade-offs 
>> ___
>> swift-build-dev mailing list
>> swift-build-...@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-build-dev
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Robert Widmann via swift-evolution]

As the author of the patch that introduced this and the patch that will come 
out of this discussion, I have no problems one way or the other.  Just bear in 
mind that if $ is an identifier head character then it cannot be used in 
operators - something I have a library with a vested interest in.

~Robert Widmann

> On Oct 14, 2016, at 3:59 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0144: Allow Single Dollar Sign as a Valid Identifier" 
> begins now and runs through October 18. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to 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
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Hooman Mehr via swift-evolution]

I don’t think $ will be become available to be used as an operator if we remove 
its identifier use. 

> On Oct 14, 2016, at 1:49 PM, Daniel Duan via swift-evolution 
>  wrote:
> 
> Agree with Robert here. I'd rather be able to use it as part of operators. 
> Currently the character set for operators and identifier head are mutually 
> exclusive. So this proposal will remove that possibility. This deserves some 
> discussion.
> 
> Daniel Duan
> Sent from my iPhone
> 
> On Oct 14, 2016, at 1:33 PM, Robert Widmann via swift-evolution 
> > wrote:
> 
>> As the author of the patch that introduced this and the patch that will come 
>> out of this discussion, I have no problems one way or the other.  Just bear 
>> in mind that if $ is an identifier head character then it cannot be used in 
>> operators - something I have a library with a vested interest in.
>> 
>> ~Robert Widmann
>> 
>>> On Oct 14, 2016, at 3:59 PM, Chris Lattner via swift-evolution 
>>> > wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of "SE-0144: Allow Single Dollar Sign as a Valid Identifier" 
>>> begins now and runs through October 18. The proposal is available here:
>>> 
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md
>>>  
>>> 
>>> 
>>> Reviews are an important part of the Swift evolution process. All reviews 
>>> should be sent to the swift-evolution mailing list at
>>> 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>>> 
>>> or, if you would like to keep your feedback private, directly to the review 
>>> manager.
>>> 
>>> What goes into a review?
>>> 
>>> The goal of the review process is to improve the proposal under review 
>>> through constructive criticism and contribute to 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
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/process.md 
>>> 
>>> 
>>> Thank you,
>>> 
>>> -Chris Lattner
>>> Review Manager
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Matthew Johnson via swift-evolution]

>   * What is your evaluation of the proposal?

-1.  I don’t like the idea of a user-defined `$` identifier.  I agree with the 
reasons for removing it.  If it is allowed as a user-defined entity it feels an 
operator is more appropriate.  Otherwise, it could be reserved as a special, 
compiler-defined identifier (like that `$n` closure argument identifiers) for 
future use in some way.

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

No, removing it was a good decision.

>   * Does this proposal fit well with the feel and direction of Swift?

No.  Despite it’s use in some popular libraries it has always seemed out of 
place as an identifier to me.

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

I have used JavaScript libraries that use this convention.  I don’t think this 
style of library design is a good fit for Swift.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Quick read.

> 
> More information about the Swift evolution process is available at


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Chris Lattner via swift-evolution]

Hello Swift community,

The review of "SE-0144: Allow Single Dollar Sign as a Valid Identifier" begins 
now and runs through October 18. The proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review 
manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and contribute to 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

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Hooman Mehr via swift-evolution]

+1. I am in favor of keeping and documenting single dollar sign as a valid 
identifier.

I personally find it very convenient to have it as a valid identifier, although 
I don’t use Dollar library.

> On Oct 14, 2016, at 12:59 PM, Chris Lattner  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0144: Allow Single Dollar Sign as a Valid Identifier" 
> begins now and runs through October 18. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to 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
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Felipe Cypriano via swift-evolution]

-1

I agree with the motivations to remove it.


On Fri, Oct 14, 2016, at 12:59, Chris Lattner via swift-evolution wrote:
> Hello Swift community,
>
> The review of "SE-0144: Allow Single Dollar Sign as a Valid
> Identifier"
> begins now and runs through October 18. The proposal is
> available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md
>
> Reviews are an important part of the Swift evolution process.
> All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to 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
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
>
>
> _
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Daniel Duan via swift-evolution]

Agree with Robert here. I'd rather be able to use it as part of operators. 
Currently the character set for operators and identifier head are mutually 
exclusive. So this proposal will remove that possibility. This deserves some 
discussion.

Daniel Duan
Sent from my iPhone

> On Oct 14, 2016, at 1:33 PM, Robert Widmann via swift-evolution 
>  wrote:
> 
> As the author of the patch that introduced this and the patch that will come 
> out of this discussion, I have no problems one way or the other.  Just bear 
> in mind that if $ is an identifier head character then it cannot be used in 
> operators - something I have a library with a vested interest in.
> 
> ~Robert Widmann
> 
>> On Oct 14, 2016, at 3:59 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> Hello Swift community,
>> 
>> The review of "SE-0144: Allow Single Dollar Sign as a Valid Identifier" 
>> begins now and runs through October 18. The proposal is available here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>>  https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager.
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and contribute to 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
>> 
>>  https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> Thank you,
>> 
>> -Chris Lattner
>> Review Manager
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[orta therox via swift-evolution]

Same, yeah 

> On 14 Oct 2016, at 21:21, Eloy Durán via swift-build-dev 
>  wrote:
> 
>> 5. Given that many people agree there are two workflows (we ourselves had 
>> talked about this a lot when writing the proposal, but didn't put it in), we 
>> felt it makes sense to consider adding that as an explicit declaration 
>> *somewhere*.
>> 
>> @Eloy, @Orta: Suppose we had a semantic notion of which packages were 
>> intended to be "top-level" versus used as a dependency, and we chose our 
>> defaults accordingly (in this case, we would orient workflows towards 
>> pinning by default in the top-level case, in the used as a dependency case 
>> we would orient away from it, e.g. warning you if you checked it in). What 
>> would you think of such a design?
> 
> Oooh, I like it.
> 
> Even though I would probably still pin/lock personally, I think this default 
> combined with the explicit declaration strikes a perfect balance in 
> trade-offs 
> ___
> swift-build-dev mailing list
> swift-build-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Daniel Dunbar via swift-evolution]

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: 
>> https://github.com/yarnpkg/yarn/issues/838#issuecomment-253362537 
>>  
> 
> This was a powerful description for me. @Rob thank you for providing that!
> 
> The articulation of the purpose/philosophy behind the whole thing was really 
> clear and made sense to me. Even though I've never used Rust or Cargo. Nor 
> have I ever run into any problems with npm such that I would prefer yarn over 
> it. I've used Bundler for years and love it.
> Yehuda Katz has been involved in making 3 different package managers for 3 
> different communities/languages over at least a 6-year span. It feels trite 
> but it seems likely he has knowledge/experience we might not. It might be 
> wise to seriously consider the wisdom of others with experience.
> 
> I will say that like others on this thread prefer determinism in my builds.
> 
> Whatever path leads me there is the path I want to walk. I'm not smart enough 
> to say if this proposal will preclude that or not. I am moved by the notion 
> that there are successful package managers out there as examples which today 
> achieve that goal. 

Alexis, Huon and I just had an in person conversation about this thread, and I 
wanted to post a summary:

1. I think there is some confusion in the thread based on us not describing in 
the proposal exactly how the package manager *behaves today*, and the parts 
which we expected to be unchanged.

We effectively "pin locally" today, in the sense that we *never* update a 
dependency without the users involvement, and we all agree we should never ever 
ever ever do this. I don't personally understand how any tool would ever not do 
this, so I may have skipped over clarifying this. I'm not sure if there was 
confusion on this point, but if so, hopefully that helps.

We also give you a way to "see" what you are pinned at with `swift package 
show-dependencies`.

What this proposal about is in one sense being able to export and share those 
pins.

2. Huon, Alexis, and I all agree we should never *inherit* pins by default.

3. Huon pointed out using "shared" to mean "package intended to be used as a 
dependency" isn't correct, since one might often share a package intended to 
just be built and used as a command line tool. OTOH, I personally don't care 
for library vs executable since executables can often be used as dependencies 
for server-side stuff, or as build tools.

4. We also all agree that there are effectively two very different workflows 
based on whether a package is intended to be a dependency.

We have three very interesting ecosystems:
A. Using packages as macOS/iOS/etc app dependencies.
B. Using packages for server-side Swift code.
C. Using packages to directly build command line tools and applications 
you can install.

In (A), all packages are dependencies, so our emphasis is on workflows oriented 
towards that.

In (B), we expect somewhat more sophistication around management of the pin 
file (w.r.t. PaaS deployment, continuous delivery, etc.), and so Huon and I at 
least agreed it was somewhat irrelevant. Also, we expect that more people 
developing in this space will simultaneously be factoring out packages which 
are intended to be dependencies.

In (C), by definition the most interesting and heavily used (as in installed) 
packages are *not* generally dependencies.

Today, (A) is a huge focus, and (B) is the main current consumer of SwiftPM. 
(C) is very interesting, and many of us would love to us it, but the reality is 
I don't see many people doing development in this space versus simply 
publishing via Homebrew, etc. Given that, my position is that *most* of the 
ecosystem is oriented towards packages which are intended to be dependencies, 
and we should choose our defaults accordingly.

5. Given that many people agree there are two workflows (we ourselves had 
talked about this a lot when writing the proposal, but didn't put it in), we 
felt it makes sense to consider adding that as an explicit declaration 
*somewhere*.

@Eloy, @Orta: Suppose we had a semantic notion of which packages were intended 
to be "top-level" versus used as a dependency, and we chose our defaults 
accordingly (in this case, we would orient workflows towards pinning by default 
in the top-level case, in the used as a dependency case we would orient away 
from it, e.g. warning you if you checked it in). What would you think of such a 
design?

 - Daniel

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Eloy Durán via swift-evolution]

> 5. Given that many people agree there are two workflows (we ourselves had 
> talked about this a lot when writing the proposal, but didn't put it in), we 
> felt it makes sense to consider adding that as an explicit declaration 
> *somewhere*.
> 
> @Eloy, @Orta: Suppose we had a semantic notion of which packages were 
> intended to be "top-level" versus used as a dependency, and we chose our 
> defaults accordingly (in this case, we would orient workflows towards pinning 
> by default in the top-level case, in the used as a dependency case we would 
> orient away from it, e.g. warning you if you checked it in). What would you 
> think of such a design?

Oooh, I like it.

Even though I would probably still pin/lock personally, I think this default 
combined with the explicit declaration strikes a perfect balance in trade-offs 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Change location of 'try' for infix operators

[John McCall via swift-evolution]

> On Oct 11, 2016, at 12:04 AM, Karl via swift-evolution 
>  wrote:
>> 
>> On 11 Oct 2016, at 08:49, Benjamin Spratling > > wrote:
>> 
>> Howdy,
>> The error message is not saying that aFunction throws, it says “??" might 
>> throw.  After all, you supplied a ()rethrows->(Int) to it as its second 
>> argument, which is wrapping a ()throws->Int, “bFunction()"
>> ?? and && and || wrap the trailing expression in an @autoclosure.
>> 
>> I am a little surprised two “try” are not required.  This would be my 
>> expectation:
>>> let value = try aFunction() ?? try bFunction()
>> but, using try to the right of a non-assignment operator is not allowed.
>> 
>> This, however, is not disallowed:
>> 
>> let value = try aFunction() ?? (try bFunction())
>> 
>> The purpose of the @autoclosure is to make developers forget they need to 
>> write a closure, and it apparently worked for you.
>> 
>> -Ben Spratling
>> 
> 
> Yeah, I understand the reason for it, but I still think we should change it 
> so you write the ‘try’ before the part which actually throws. Perhaps the 
> rule should be something more general around rethrowing autoclosures?
> 
> After all, I thought that was the entire point of the ‘try’ keyword. The 
> compiler doesn't really need it (it already knows what throws and what 
> doesn’t), but it helps humans to mark where the throwing stuff happens.

I agree that you should be able to place the try inside the autoclosure and 
have that propagate out.  This doesn't need evolution discussion; please file a 
bug.

John.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Kevin Ballard via swift-evolution]

On Fri, Oct 14, 2016, at 12:59 PM, Chris Lattner wrote:
>   * What is your evaluation of the proposal?

-1. I agree with the reasons for removal, and do not consider the existence of 
a single library that depends on undocumented behavior to be sufficient reason 
for this change.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

A quick reading.

-Kevin Ballard
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private & fileprivate

[Nevin Brackett-Rozinsky via swift-evolution]

On Fri, Oct 14, 2016 at 11:51 AM, Daniel Duan  wrote:

>
> On Oct 13, 2016, at 9:03 PM, Nevin Brackett-Rozinsky <
> nevin.brackettrozin...@gmail.com> wrote:
>
> Daniel, I would be interested to hear what, exactly, are the benefits your
> project has realized from the new “private” compared to the old “private”
> (which is now called “fileprivate”).
>
> There's no amazing insight here. The benefit is more granular control. The
> more people work on a project, the more useful this becomes.
>

More granular control *within a single file*. That is where I have a hard
time imagining the benefits, and thus am asking for details.

If there are multiple types within a single file, it is usually because
they need to share implementation details.

The only things that I see which scope-based access (the new “private”)
brings to the table are:
• Scope-private members from other parts of the file are unavailable (and
thus don’t show in autocomplete).
• Different extensions of a type can have scope-private members with the
same name as each other.

The former seems negligible, because you are working *within the same
file*. The API that a type vends within its own file is hardly worth
optimizing for.

And the latter I would say is an anti-feature. Using multiple different
members with the same name in extensions just makes it harder to rearrange
the implementation, because those scope-private members will collide if
moved into the same extension.

So I *really* don’t see the benefits. Yes, I understand that there is now
more granular control over access within a single file. I am asking for
examples of how that additional granularity provides *benefits*.


 On Fri, Oct 14, 2016 at 11:51 AM, Daniel Duan  wrote:

> You might as well ask "why not make everything public" if private and
> fileprivate makes no difference to you.
>

That is not a fair assertion at all. The API which a type vends to other
files within its module, and to clients outside its module, are significant
parts of a quality and maintainable design.

I do not think the API which a type vends *within its own file* warrants
such lofty prioritization.



> On Fri, Oct 14, 2016 at 11:51 AM, Daniel Duan  wrote:
>
>>
>> On Oct 13, 2016, at 9:03 PM, Nevin Brackett-Rozinsky <
>> nevin.brackettrozin...@gmail.com> wrote:
>>
> As I see it, two significant drawbacks of the new “private” are increased
> complexity in the access control model, and encumbrance of the old
> “private” with the unwieldy moniker “fileprivate”.
>
> The first drawback is a truism: every language addition of feature makes
> it more complex.
>

You can’t just write off the complexity cost like that. The new scope-based
“private” access level brings *substantial* complexity, to both the
implementation and the mental programming model. It creates *unutterable*
access levels, where a scope can see a member of another scope, but cannot
create its own member with the same access level.


On Fri, Oct 14, 2016 at 11:51 AM, Daniel Duan  wrote:
>
> So we need to measure the benefit with other costs, which brings us to
> your second "drawback". I'm having a hard time understanding it. Is it too
> hard to type? If so, as an Objective-C survivor I disagree. The experience
> of reading code is harder and therefore more important than that of
> authoring code. "fileprivate" was chosen over many other alternatives
> because it's obvious to the reader. A shorter but equally obvious name
> would have been nice. But "unwieldy" is not enough reason to justify such
> source-breaking change at the moment.
>

Right, “unwieldy” is not enough to justify a source-breaking change. I
entirely agree.

It is the *complexity* of the current model that would justify the
source-breaking change, if it does not have real benefits which stand on
their own and outweigh the costs.

What unwieldiness *does* justify is a non-breaking change, such as
introducing “privy” (or something else) as a synonym for “fileprivate”,
then eventually deprecating and removing the latter.

• • •

I will also note that the principal practical effect of SE-0025 was
“Replace a small number of occurrences of ‘private’ with ‘fileprivate’.”

That is essentially all it did to source code. It brought a significant
increase to the complexity of the access control model, in order to make a
few member declarations lengthier and more awkward.

Maybe there are other benefits, but I have not seen them.

• • •

Let me reiterate my stance: if the new scope-based “private” has benefits
which outweigh its complexity cost, then we should keep it. Otherwise we
should get rid of scope-based access control and reinstate the old
file-based “private”.

Furthermore, we should rename “fileprivate” to something shorter and less
awkward, which will play nice with submodules. If “private” is off the
table then I propose “privy”, though I welcome other suggestions.

 Nevin

If the new “private” has brought 

[swift-evolution] Tuples as RawRepresentable

[Haravikk via swift-evolution]

Following on from discussion about stored properties for enums, I've decided to 
split off discussion about the possibility of enabling tuples as raw values.

Currently to enable multi-part raw values we need to define a struct that 
conforms to RawRepresentable; this involves a lot of boilerplate however, and 
seems like exactly the kind of thing that tuples are ideally suited towards 
simplifying.

To make tuples automatically conform to RawRepresentable will likely require 
some compiler magic, but I think it's worth doing, and should be doable with 
the following additions:

A TupleType protocol (uncertain of correct name for it) to which all specific 
tuple types will automatically conform, and to which user-defined types may 
not. This is simply a marker type for now (no methods etc.), as it is 
essentially just to enable the following:
An ExpressableAsTuple protocol, following the same style as other 
ExpressableAs* protocols, with the associated type conforming to TupleType, 
thus requiring that it be a specific tuple definition. All specific tuple types 
are automatically expressible as themselves.
All tuples will then conform to RawRepresentable, simply returning themselves 
as their raw value. This may require some magic as well, since I don't know if 
we want tuples to gain a .rawValue property or not, so could be exposed only 
when handling them as RawRepresentable specifically?

With ExpressableAsTuple recognised as RawRepresentable, I believe this should 
satisfy all requirements such that enums, and other types requiring literals, 
will be able to accept tuples in addition to the types that they currently do.

I think I've covered the requirements here, and I'm hoping someone can confirm 
if this looks correct. Of course I'm open to any other suggestions on how we 
might enable tuples as literals, especially if there's an easier way!___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private & fileprivate

[Ted F.A. van Gaalen via swift-evolution]

Most disturbing, 
What are you trying to achieve?

Well, I can be a little harsh at times too, perhaps at times
when I do not fully understand or misinterpret situations or people.
in that case I will admit my shortcoming and apologise if necessary.

However, you are being very negative, rude and insulting,
Btw, I also work with Smalltalk and assure that you are 
completely out of touch with the Smalltalk community
which is very friendly and social and so is the Swift community.

I see no need to further converse with you.

TedvG






> On 14 Oct 2016, at 02:14, Trans  wrote:
> 
> Sorry, that was a little harsh. I just think there are a lot of
> opinions here based on personal biases and not necessary the best
> prior experiences. If you want good OOP it is best to let people with
> *real* OOP experience, like SmallTalk, work it out.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Tuples as RawRepresentable

[Haravikk via swift-evolution]

> On 14 Oct 2016, at 09:49, David Sweeris  wrote:
> 
> I'm very much in favor of the functionality, but I don't think the 
> implementation should rely on compiler magic.
> 
> - Dave Sweeris 

Well it's not too much in the way of magic really, more just that we need Swift 
to see tuples as conforming to RawRepresentable and ExpressableAsTuple, 
although they currently aren't types in the normal sense. So the protocols 
being used will be the same as you might use yourself, they'll just be applied 
automatically for tuples.

It'd be neat if it could be done properly, but that could involve even more 
work, but doing this automatically for now should be fairly simple (though I 
say that as a person who wouldn't be the one doing it ;)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Tuples as RawRepresentable

[David Sweeris via swift-evolution]

I'm very much in favor of the functionality, but I don't think the 
implementation should rely on compiler magic.

- Dave Sweeris 

> On Oct 14, 2016, at 03:24, Haravikk via swift-evolution 
>  wrote:
> 
> Following on from discussion about stored properties for enums, I've decided 
> to split off discussion about the possibility of enabling tuples as raw 
> values.
> 
> Currently to enable multi-part raw values we need to define a struct that 
> conforms to RawRepresentable; this involves a lot of boilerplate however, and 
> seems like exactly the kind of thing that tuples are ideally suited towards 
> simplifying.
> 
> To make tuples automatically conform to RawRepresentable will likely require 
> some compiler magic, but I think it's worth doing, and should be doable with 
> the following additions:
> 
> A TupleType protocol (uncertain of correct name for it) to which all specific 
> tuple types will automatically conform, and to which user-defined types may 
> not. This is simply a marker type for now (no methods etc.), as it is 
> essentially just to enable the following:
> An ExpressableAsTuple protocol, following the same style as other 
> ExpressableAs* protocols, with the associated type conforming to TupleType, 
> thus requiring that it be a specific tuple definition. All specific tuple 
> types are automatically expressible as themselves.
> All tuples will then conform to RawRepresentable, simply returning themselves 
> as their raw value. This may require some magic as well, since I don't know 
> if we want tuples to gain a .rawValue property or not, so could be exposed 
> only when handling them as RawRepresentable specifically?
> 
> With ExpressableAsTuple recognised as RawRepresentable, I believe this should 
> satisfy all requirements such that enums, and other types requiring literals, 
> will be able to accept tuples in addition to the types that they currently do.
> 
> I think I've covered the requirements here, and I'm hoping someone can 
> confirm if this looks correct. Of course I'm open to any other suggestions on 
> how we might enable tuples as literals, especially if there's an easier way!
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private & fileprivate

[Charles Srstka via swift-evolution]

> On Oct 13, 2016, at 1:25 AM, Jean-Daniel via swift-evolution 
>  wrote:
> 
> I don’t think monitoring the usage of private vs fileprivate is fair. By 
> default, people will use private until they encounter visibility issues and 
> discover they need to change to fileprivate. So private will probably being 
> use far more than fileprivate.
> Nonetheless it does not mean people chosen private because it effectively 
> reduce the visibility to the class scope, but just because it is easier to 
> discover and to type than fileprivate and fit in many cases.

How is that an argument against private, though? If private is used far more 
often than fileprivate, then this suggests that the vast amount of the time, 
the scope it provides is what is appropriate. The enlarged scope provided by 
fileprivate, then, is needed for what are essentially edge cases. It makes 
little sense, to my mind, to replace the mainstream option with the niche one.

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[orta therox via swift-evolution]

Please don’t make this a separate command, it should ideally be created at the 
end of an build (when there isn’t one already) or an update of your 
dependencies - most people will be expecting to get the same set of 
dependencies as the rest of their team. This pattern makes that harder.

NPM shrinkwrap is an example of this, and it’s a bad one - I’ve wasted a lot of 
time trying to keep that up to date for our npm projects. Facebook made a 
replacement for NPM with mainly the  feature of “always locking” in yarn 
 and I’d expect that to take a lot of the JS mindshare on 
this one feature alone.

-- 

[A.]Orta Therox

> w/ Artsy CocoaPods  / CocoaDocs 
>  / GIFs.app 
> 
> @orta  / orta.github.com 
> Artsy is totally hiring iOS Devs  ATM

> On 14 Oct 2016, at 07:01, Ankit Aggarwal via swift-build-dev 
>  wrote:
> 
> Hi,
> 
> We're proposing version pinning feature in Swift Package Manager. The 
> proposal is available here 
> 
>  and also in this email:
> 
> Feedback welcomed!
> 
> Thanks,
> Ankit
> 
> 
> 
> Package Manager Version Pinning
> Proposal: SE-
> Author: Daniel Dunbar , Ankit Aggarwal 
> 
> Review Manager: TBD
> Status: Discussion
> Introduction
> This is a proposal for adding package manager features to "pin" or "lock" 
> package dependencies to particular versions.
> 
> Motivation
> As used in this proposal, version pinning refers to the practice of 
> controlling exactly which specific version of a dependency is selected by the 
> dependency resolution algorithm, independent from the semantic versioning 
> specification. Thus, it is a way of instructing the package manager to select 
> a particular version from among all of the versions of a package which could 
> be chosen while honoring the dependency constraints.
> 
> Terminology
> 
> We have chosen to use "pinning" to refer to this feature, over "lockfiles", 
> since the term "lock" is already overloaded between POSIX file locks and 
> locks in concurrent programming.
> 
> Philosophy
> 
> Our philosophy with regard to pinning is that we actively want to encourage 
> packages to develop against the latest semantically appropriate versions of 
> their dependencies, in order to foster rapid development amongst the 
> ecosystem and strong reliance on the semantic versioning concept. Our design 
> for version pinning is thus intended to be a feature for package authors and 
> users to use in crafting specific workflows, not be a mechanism by which most 
> of the packages in the ecosystem pin themselves to specific versions of each 
> other.
> 
> Use Cases
> 
> Our proposal is designed to satisfy several different use cases for such a 
> behavior:
> 
> Standardizing team workflows
> 
> When collaborating on a package, it can be valuable for team members (and 
> continuous integration) to all know they are using the same exact version of 
> dependencies, to avoid "works for me" situations.
> 
> This can be particularly important for certain kinds of open source projects 
> which are actively being cloned by new users, and which want to have some 
> measure of control around exactly which available version of a dependency is 
> selected.
> 
> Difficult to test packages or dependencies
> 
> Complex packages which have dependencies which may be hard to test, or hard 
> to analyze when they break, may choose to maintain careful control over what 
> versions of their upstream dependencies they recommend -- even if 
> conceptually they regularly update those recommendations following the true 
> semantic version specification of the dependency.
> 
> Dependency locking w.r.t. deployment
> 
> When stabilizing a release for deployment, or building a version of a package 
> for deployment, it is important to be able to lock down the exact versions of 
> dependencies in use, so that the resulting product can be exactly recreated 
> later if necessary.
> 
> Proposed solution
> We will introduce support for an optional new file Package.pins adjacent to 
> the Package.swift manifest, called the "pins file". We will also introduce a 
> number of new commands (see below) for maintaining the pins file.
> 
> This file will record the active version pin information for the package, 
> including data such as the package identifier, the pinned version, and 
> explicit information on the pinned version (e.g., the commit hash/SHA for the 
> resolved tag).
> 
> The exact file format is unspecified/implementation defined, however, in 
> practice it will be a JSON data file.
> 
> This file may be checked into SCM by the user, so that 

Re: [swift-evolution] private & fileprivate

[Jamie Lemon via swift-evolution]

I agree with Ted that I would have expected the inner members of a class to be 
private by default. (Not a big deal if I have to explicitly prefix most of my 
concerned vars now - but it is just different to what I would have expected). 
Certainly, in the past, I would be more used to having to explicitly define 
chosen vars as “public” ( e.g. in the past world of Objective C I  was used to 
defining selected vars with @synthesize to “open them up" )

On 13 Oct 2016, at 22:27, Ted F.A. van Gaalen via swift-evolution 
> wrote:

Please do NOT drop the current distinction between *private* and *fileprivate*
as it is now in Swift 3
It is needed for correct OOP.

As written before, but now a bit more compact, I hope:

I would like to have the inner members of a class as default private,
(not fileprivate)  that is, that each entity inside the class body is not 
visible
in the outer scope. not even in the same file!

I would only reveal entities of a class to the outer scope that are 
needed.there.
(as is the case with class properties in Objective-C and most other OOP 
supporting languages)

This is what I have to do now,
Each and every entity that I wish to keep hidden
I have to prefix with *private*: like in this example class:
This is tedious and should be unnecessary.

class TG3DGauge: SCNNode
{

private var needles = [SCNNode]()
private var fmtStr = “" // private should be the default!

var value: CGFloat = 0  // access default “internal”! Visible to the 
outside world.
{
didSet  // trigger value change, rotate needles etc.
{
valueChange()
}
}

private var nodeUnitText = SCNNode()
private var nodeValueText = SCNNode()

private var valRange: ClosedRange = (0...100.0)
private var valScaleFactor: CGFloat = 1

// etc. much more stuff here and
// most of it should be private, that is
// only visible within the class body!
.
.
} // end class TG3DGauge

If I don’t specify an access modifier, then the default
for the items defined in classes is *internal*,
which means that these items are visible in the whole application source.

However, this is only desirable for items that I want to
reveal explicitly, of course.
That is exactly why I need the *private* access modifier as it is now
and not *fileprivate*
So I am very glad that this access modifier *private* finally became
available in Swift 3

In my classes, *private* is probably the most used keyword, but
*private* should be the default for entities within a class body
just like it is for entities within functions.

As far as I know, prefixing with *private* is the only solution in Swift to 
protect
functions, vars etc. in my class against unwanted access
from the outer scope. I think this is not the way it should be.

Making all entities in a class private prevents this.
and offers also reasonable protection against
the Fragile Base Class problem, (thanks Chris for url) :
 https://en.wikipedia.org/wiki/Fragile_base_class

A solution for as it is now, albeit not a perfect one would be,
to have some sort of access modifier which defines
all items within the class to be private by default.
perhaps the keyword *closedscope* like in this example:

closedscope class TG3DGauge: SCNNode
{

var needles = [SCNNode]()  // is now private by default
var fmtStr = “"// is now private by default

public var value: CGFloat = 0 // Public!! visible outside class
   // “fileprivate" or “internal”  can also be used.
{
didSet  // trigger value change, rotate needles etc.
{
valueChange()
}
}

var nodeUnitText = SCNNode()  // is now private by default
var nodeValueText = SCNNode() // is now private by default

//etc.


Again, for this reasons, don’t drop the distinction between
between *fileprivate* and *private*
if this is done, there is afaics no way to protect items within a class body.
Leave it as it is now, please. (also to prevent source breaking as well)

(btw, the above TG3DGauge class is a perfect example:
With real gauges it would not be a good idea if one can touch
the needles and gears inside the gauge’s casing,
which is exactly the case with OOP. e.g.
In my class example people would e.g. be able to set the angle
from needles (if not declared private)  directly, without updating the value.)


TedvG
www.tedvg.com  (see my gauges from above class here)



Le 13 oct. 2016 à 07:52, Chris Lattner via swift-evolution 
> a écrit :

On Oct 12, 2016, at 9:56 PM, Russ Bishop via swift-evolution 
 
> wrote:
I actually consider it very lucky that most of our changes so far have been 
fairly non-controversial. Everybody has a different idea of what 

Re: [swift-evolution] private & fileprivate

[Goffredo Marocchi via swift-evolution]

Well, this is some good attitude ;).

Sent from my iPhone

> On 14 Oct 2016, at 00:50, Trans via swift-evolution 
>  wrote:
> 
> On Thu, Oct 13, 2016 at 5:27 PM, Ted F.A. van Gaalen via
> swift-evolution  wrote:
>> Please do NOT drop the current distinction between *private* and
>> *fileprivate*
>> as it is now in Swift 3
>> It is needed for correct OOP.
> 
> Sorry, but that is laughable. So far I haven't seen a sole on here
> that seems to really know anything about OOP. You all are just copying
> and extrapolating on ObjC/C++/Java. Which got it all sorts of wrong
> from the get go.
> 
> Go learn you some SmallTalk for the greater good.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Paul Cantrell via swift-evolution]

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 being able to export and share those 
> pins.

This is a crucial and clarifying insight. It should be in the proposal! Near 
the top.

> 2. Huon, Alexis, and I all agree we should never *inherit* pins by default.

Indeed. Pins should be only be about sharing specific versions within a 
development team — not with client packages / apps. What’s pinned in Vegas 
stays in Vegas. Publishing pins to other projects would be nonsensical.

> 5. Given that many people agree there are two workflows (we ourselves had 
> talked about this a lot when writing the proposal, but didn't put it in), we 
> felt it makes sense to consider adding that as an explicit declaration 
> *somewhere*.
> 
> @Eloy, @Orta: Suppose we had a semantic notion of which packages were 
> intended to be "top-level" versus used as a dependency, and we chose our 
> defaults accordingly (in this case, we would orient workflows towards pinning 
> by default in the top-level case, in the used as a dependency case we would 
> orient away from it, e.g. warning you if you checked it in). What would you 
> think of such a design?

I’m puzzled. If a package’s pinning does not affect any other package that uses 
it, why should the defaults be different? A library will still suffer from all 
the “works for me” problems an app might.

Is the rationale that not pinning libraries encourages accidental testing of 
new versions of a library’s dependencies as they arrive? Or is there another 
rationale for having different defaults?

Cheers, P

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Johannes Weiß via swift-evolution]

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, trusting them to properly apply SemVer is the 
> same issue.

maybe we should have the tooling support that? Elm does try to enforce correct 
semantic versioning. Maybe swift-pm should do that too?

See http://elm-lang.org :

Enforced Semantic Versioning

Elm can detect all API changes automatically thanks to its type system. We use 
that information to force everything in our package catalog to follow semantic 
versioning precisely. No more surprises in PATCH releases!


I have no idea how well it works but if we'll end up relying on proper semantic 
versioning, tool support sounds like a good idea to me.


> [...]

Cheers,
  Johannes
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Daniel Dunbar via swift-evolution]

> 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 being able to export and share 
>> those pins.
> 
> This is a crucial and clarifying insight. It should be in the proposal! Near 
> the top.

Good idea, will incorporate it.

>> 2. Huon, Alexis, and I all agree we should never *inherit* pins by default.
> 
> Indeed. Pins should be only be about sharing specific versions within a 
> development team — not with client packages / apps. What’s pinned in Vegas 
> stays in Vegas. Publishing pins to other projects would be nonsensical.
> 
>> 5. Given that many people agree there are two workflows (we ourselves had 
>> talked about this a lot when writing the proposal, but didn't put it in), we 
>> felt it makes sense to consider adding that as an explicit declaration 
>> *somewhere*.
>> 
>> @Eloy, @Orta: Suppose we had a semantic notion of which packages were 
>> intended to be "top-level" versus used as a dependency, and we chose our 
>> defaults accordingly (in this case, we would orient workflows towards 
>> pinning by default in the top-level case, in the used as a dependency case 
>> we would orient away from it, e.g. warning you if you checked it in). What 
>> would you think of such a design?
> 
> I’m puzzled. If a package’s pinning does not affect any other package that 
> uses it, why should the defaults be different? A library will still suffer 
> from all the “works for me” problems an app might.
> 
> Is the rationale that not pinning libraries encourages accidental testing of 
> new versions of a library’s dependencies as they arrive? Or is there another 
> rationale for having different defaults?

I'll defer to this comment (linked from someone else earlier in the thread), 
which happens to match up with my perspective:
  https://github.com/yarnpkg/yarn/issues/838#issuecomment-253362537

 - Daniel

> 
> Cheers, P
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Eloy Durán via swift-evolution]

>> [...]
>> 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, trusting them to properly apply SemVer is the 
>> same issue.
> 
> maybe we should have the tooling support that? Elm does try to enforce 
> correct semantic versioning. Maybe swift-pm should do that too?
> 
> See http://elm-lang.org :
> 
> Enforced Semantic Versioning
> 
> Elm can detect all API changes automatically thanks to its type system. We 
> use that information to force everything in our package catalog to follow 
> semantic versioning precisely. No more surprises in PATCH releases!
> 
> 
> I have no idea how well it works but if we'll end up relying on proper 
> semantic versioning, tool support sounds like a good idea to me.

This is what I was referring to when I mentioned that automation can only take 
you so far. It is easily possible to do a patch release where the API might not 
change, but the semantics of the code does.

In my opinion it requires human judgement to determine if a change is really 
something you can trust. Trusting SemVer for that is going to lead to problems 
and making people think that they can is just misleading in my book.

Not saying you can’t have tools to help guide choosing versions, though.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Paul Cantrell via swift-evolution]

> 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 the defaults be different? A library will still suffer 
>> from all the “works for me” problems an app might.
>> 
>> Is the rationale that not pinning libraries encourages accidental testing of 
>> new versions of a library’s dependencies as they arrive?
> 
> Yep.

I’m skeptical of whether disabling pinning by default is the right answer. It 
seems … haphazard and incomplete, likely to confuse those who don’t understand 
this reasoning, and only incidentally helpful to those who do.

I’d prefer an approach that is more mindful, more intentional.

Emitting warnings when newer versions of packages are available would help 
address the same issue. This would also encourage apps to get security patches 
promptly.

A more ambitious approach might be to provide a utility that installs and tests 
various combinations of all the semantically allowed versions of a lib’s 
dependencies — at the very least, all the lowest and highest allowed versions. 
This would ignore any existing pinfile. Library devs would run this prior to 
release, and on a CI server if they have one.

This would have the advantage of catching incompatibilities with _past_ 
versions of libraries as well as _new_ ones. In particular, it would catch 
too-permissive version specifications, e.g. if your library asks for foolib 3.x 
but relies on a bugfix in 3.4.2, this approach would catch that problem.

That’s clearly a bigger, separate idea, not necessary to hash out right now. I 
mean it just to illustrate what better approaches might look like. I’m 
skeptical that simply disabling pinning does a good job of solving the intended 
problem, and don’t think it should weigh quite so heavily on the proposal at 
hand.

Cheers,

Paul

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Johannes Weiß via swift-evolution]

Hi Eloy,

> > [...]
>> I have no idea how well it works but if we'll end up relying on proper 
>> semantic versioning, tool support sounds like a good idea to me.
> 
> This is what I was referring to when I mentioned that automation can only 
> take you so far. It is easily possible to do a patch release where the API 
> might not change, but the semantics of the code does.
> 
> In my opinion it requires human judgement to determine if a change is really 
> something you can trust. Trusting SemVer for that is going to lead to 
> problems and making people think that they can is just misleading in my book.
> 
> Not saying you can’t have tools to help guide choosing versions, though.

agreed. But I think that if (whether that's good or bad) we rely on semantic 
versioning, tool support can make that a lot easier.

Cheers,
  Johannes
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Daniel Dunbar via swift-evolution]

> 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, trusting them to properly apply SemVer is the 
>> same issue.
> 
> maybe we should have the tooling support that? Elm does try to enforce 
> correct semantic versioning. Maybe swift-pm should do that too?

We would like to (try to), and it is on the long list of ideal future things to 
do. It requires a lot of compiler support no one has signed up for yet, 
though...

 - Daniel

> See http://elm-lang.org :
> 
> Enforced Semantic Versioning
> 
> Elm can detect all API changes automatically thanks to its type system. We 
> use that information to force everything in our package catalog to follow 
> semantic versioning precisely. No more surprises in PATCH releases!
> 
> 
> I have no idea how well it works but if we'll end up relying on proper 
> semantic versioning, tool support sounds like a good idea to me.
> 
> 
>> [...]
> 
> Cheers,
>  Johannes

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Daniel Duan via swift-evolution]

> On Oct 14, 2016, at 3:42 PM, Alex Martini via swift-evolution 
>  wrote:
> 
>> On Oct 14, 2016, at 1:53 PM, Hooman Mehr via swift-evolution 
>> > wrote:
>> 
>>> On Oct 14, 2016, at 1:49 PM, Daniel Duan via swift-evolution 
>>> > wrote:
>>> 
>>> Agree with Robert here. I'd rather be able to use it as part of operators. 
>>> Currently the character set for operators and identifier head are mutually 
>>> exclusive. So this proposal will remove that possibility. This deserves 
>>> some discussion.
>>> 
>>> Daniel Duan
>>> Sent from my iPhone
>> 
> 
>> I don’t think $ will be become available to be used as an operator if we 
>> remove its identifier use. 
> 
> 
> If $ is an operator, then "$2" looks like the custom unary prefix operator 
> "$" applied to "2".  That's a problem; it needs to be parsed as the 
> identifier "$2" instead.
> 
> We could prevent "$" from being allowed a prefix operator.  There is 
> precedent for the language reserving operators that would otherwise be 
> allowed, such as postfix "?" and postfix "!".
> 

Yes, we might have to special case the parser for this. I imagine some flag 
such as “isParsingClosureWithoutExplicitParameter”. At least it’s not 
impossible 

> — Alex
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Charles Srstka via swift-evolution]

> On Oct 14, 2016, at 2:59 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0144: Allow Single Dollar Sign as a Valid Identifier" 
> begins now and runs through October 18. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to 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
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager

> * What is your evaluation of the proposal?

-1. What is the point of this?

> * Is the problem being addressed significant enough to warrant a change to 
> Swift?

The “problem” seems to be that one specific library misused a character that 
was not documented to be legal in an identifier. The solution would seem to be 
to fix the library, not change the language.

> * Does this proposal fit well with the feel and direction of Swift?

No, it does not. $ by itself looks far more like an operator than an 
identifier, and $ as the beginning of an identifier conflicts with the special 
$0, $1, etc. keywords that are already used by Swift.

> * If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?

The discussion of identifiers beginning with $ brings to mind Perl and similar 
scripting languages, in which scalar variables look like $foo, $bar, etc. I 
imagine that this is why $ was chosen for the $0, $1, etc. keywords. As a 
result, when seeing something like $foo in the language, one’s mind tends to 
interpret this as a variable named “foo” with the $ doing something to it, 
describing something about it, or something similar.

> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

Read the proposal, read the thread.

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Eloy Durán via swift-evolution]

>> Not saying you can’t have tools to help guide choosing versions, though.
> 
> agreed. But I think that if (whether that's good or bad) we rely on semantic 
> versioning, tool support can make that a lot easier.

Aye, agreed.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Paul Cantrell via swift-evolution]

> On Oct 14, 2016, at 6:42 PM, Daniel Dunbar  wrote:
> 
>> On Oct 14, 2016, at 4:02 PM, Paul Cantrell  wrote:
>> 
>> I’m puzzled. If a package’s pinning does not affect any other package that 
>> uses it, why should the defaults be different? A library will still suffer 
>> from all the “works for me” problems an app might.
>> 
>> Is the rationale that not pinning libraries encourages accidental testing of 
>> new versions of a library’s dependencies as they arrive? Or is there another 
>> rationale for having different defaults?
> 
> I'll defer to this comment (linked from someone else earlier in the thread), 
> which happens to match up with my perspective:
>  https://github.com/yarnpkg/yarn/issues/838#issuecomment-253362537

I took that comment to be an explanation of why a library's lockfile/pinfile 
should not propagate to other packages that use it. That is clearly the case; 
such pin propagation would be nonsensical.

My question was not about that, but about why libraries shouldn’t use a pinfile 
at all, even for their own _internal_ development. All the same “last know good 
build” concerns apply.

The difference is that testing against that single last known good version set 
is sufficient for a top-level package, whereas a library should (1) ideally 
test against multiple valid dependency versions and (2) test often against new 
versions of its dependencies. I don’t see, however, that this implies that 
libraries should not have pinfiles at all — just that their release / CI 
process should not be limited to what’s pinned.

Cheers, P

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Will Stanton via swift-evolution]

I’m a bit curious about how `$` is/would be used as a prefix operator! Perhaps 
I’m not creative :-(

Regards,
Will Stanton

> On Oct 14, 2016, at 6:42 PM, Alex Martini via swift-evolution 
>  wrote:
> 
>> On Oct 14, 2016, at 1:53 PM, Hooman Mehr via swift-evolution 
>>  wrote:
>> 
>>> On Oct 14, 2016, at 1:49 PM, Daniel Duan via swift-evolution 
>>>  wrote:
>>> 
>>> Agree with Robert here. I'd rather be able to use it as part of operators. 
>>> Currently the character set for operators and identifier head are mutually 
>>> exclusive. So this proposal will remove that possibility. This deserves 
>>> some discussion.
>>> 
>>> Daniel Duan
>>> Sent from my iPhone
>> 
>> I don’t think $ will be become available to be used as an operator if we 
>> remove its identifier use. 
> 
> If $ is an operator, then "$2" looks like the custom unary prefix operator 
> "$" applied to "2".  That's a problem; it needs to be parsed as the 
> identifier "$2" instead.
> 
> We could prevent "$" from being allowed a prefix operator.  There is 
> precedent for the language reserving operators that would otherwise be 
> allowed, such as postfix "?" and postfix "!".

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Charles Constant via swift-evolution]

+1 for me for "in-module" as a stop-gap, since I imagine it would be the
quickest, and least disruptive, way to make this happen.

I would add the caveat that if we do so, I really hope we commit to making
stored properties available *everywhere* later.

Even though it's more often than not "in-module" where I need this, the
fewer "exceptions to the rule" we have in Swift the better. It gets tricky
trying to plan things out when one has to juggle too many features that
work in one context, but not another.

So +1 with the hope that it doesn't stay "in-module" till the end of time.



On Fri, Oct 14, 2016 at 6:01 PM, Paul Cantrell via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Oct 9, 2016, at 3:43 PM, Charles Srstka via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Let extensions introduce stored properties, but only in the same module
> as the type’s definition. Then, the compiler can just take any extensions
> into consideration when it’s determining the size of the type, just as if
> the properties had been declared in the type. Declaring stored properties
> on an extension outside of the type’s module results in a compiler error,
> exactly as today. This would, without any performance drawbacks, solve one
> of the big problems that people are hoping to solve via stored properties
> in extensions—the ability to organize members by protocol conformance.
>
> Yes please! A big strong +1 to this from me. I can think of several
> specific chunks of problem code that this would clean up immensely.
>
> Contra Karl in another message, it’s _in-module_ stored property
> extensions that I want most frequently. By far.
>
> It seems to me that Charles’s idea could be introduced as its own
> proposal. If out-of-module stored property extensions do eventually become
> feasible, then Charles’s proposal is a good stepping stone. If they never
> do, then his proposal has done no harm.
>
> I realize this probably falls into the post-ABI stability bucket, but I’d
> love to help write/support the proposal when its time comes.
>
> Cheers,
>
> Paul
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Will Stanton via swift-evolution]

> I’m a bit curious about how `$` is/would be used as a prefix operator!
Clarifying: what type of operations would it be used for, and postfix too!

Regards,
Will Stanton

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

> On 14 Oct 2016, at 07:16, Daniel Duan via swift-evolution 
>  wrote:
> 
> 1. “honor” is mis-spelled in “weird queen’s dialect”.

I'm sorry, but I throw an exception at this; when you say "weird queen's 
dialect" do you mean… English? I don't go around referring to the other 
variation as "weird can't spell dialect" (but maybe I should) 
The u in words like honour is what makes it pronounced like "onner" rather than 
"hone-ore", same with colour being "culler" rather than "coal-ore". Sorry but 
it really annoys me when people consider the English version of English to be 
the weird one, as the clue is literally in the name as to which version is 
correct. This is why it still galls me that the language in macOS is "British 
English" yet the other one is just "English" rather than "American English" or 
whatever, it's a hideous double standard.


That aside, I'm a strong +1 for the feature 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Eloy Durán via swift-evolution]

I cannot agree more with Orta.

> It drives the user away from taking full advantage of semantic versioning.

While I ideally subscribe to this thought, the truth of the matter is that this 
has proven unreliable on multiple occasions. Promoting the idea that it works 
is going to inevitably lead users into problems when they did not take explicit 
user action to update dependencies.

Semantic versioning is a great tool when you decide to sit down and explicitly 
update dependencies.

> We think it will be good for the package ecosystem if such a restriction is 
> not the default behavior and that this design will lead to faster discovery 
> of bugs and fixes in the upstream.

Again, ideally I would subscribe to this, but the truth is that when people are 
working on their projects they *really really really* do *not* like their 
builds breaking, especially not when it’s seemingly caused outside of their own 
fault.

In the end, it comes down to whether you prioritise surfacing bugs (long term 
happiness) over user-experience (short term happiness). As a dependency manager 
author, I can tell you that I agree with your ideals and would want to choose 
the former, but as a user of dependency managers I would choose UX and Getting 
(The) Things (I Really Wanted To Do) Done over surfacing bugs *any* day.

[A.]Eloy Durán
Artsy 

e...@artsy.net   Twitter 

GitHub 
> On 14 Oct 2016, at 09:29, orta therox via swift-build-dev 
>  wrote:
> 
> Please don’t make this a separate command, it should ideally be created at 
> the end of an build (when there isn’t one already) or an update of your 
> dependencies - most people will be expecting to get the same set of 
> dependencies as the rest of their team. This pattern makes that harder.
> 
> NPM shrinkwrap is an example of this, and it’s a bad one - I’ve wasted a lot 
> of time trying to keep that up to date for our npm projects. Facebook made a 
> replacement for NPM with mainly the  feature of “always locking” in yarn 
>  and I’d expect that to take a lot of the JS mindshare 
> on this one feature alone.
> 
> -- 
> 
> [A.]  Orta Therox
> 
>> w/ Artsy CocoaPods  / CocoaDocs 
>>  / GIFs.app 
>> 
>> @orta  / orta.github.com 
>> Artsy is totally hiring iOS Devs  ATM
> 
>> On 14 Oct 2016, at 07:01, Ankit Aggarwal via swift-build-dev 
>> > wrote:
>> 
>> Hi,
>> 
>> We're proposing version pinning feature in Swift Package Manager. The 
>> proposal is available here 
>> 
>>  and also in this email:
>> 
>> Feedback welcomed!
>> 
>> Thanks,
>> Ankit
>> 
>> 
>> 
>> Package Manager Version Pinning
>> Proposal: SE-
>> Author: Daniel Dunbar , Ankit Aggarwal 
>> 
>> Review Manager: TBD
>> Status: Discussion
>> Introduction
>> This is a proposal for adding package manager features to "pin" or "lock" 
>> package dependencies to particular versions.
>> 
>> Motivation
>> As used in this proposal, version pinning refers to the practice of 
>> controlling exactly which specific version of a dependency is selected by 
>> the dependency resolution algorithm, independent from the semantic 
>> versioning specification. Thus, it is a way of instructing the package 
>> manager to select a particular version from among all of the versions of a 
>> package which could be chosen while honoring the dependency constraints.
>> 
>> Terminology
>> 
>> We have chosen to use "pinning" to refer to this feature, over "lockfiles", 
>> since the term "lock" is already overloaded between POSIX file locks and 
>> locks in concurrent programming.
>> 
>> Philosophy
>> 
>> Our philosophy with regard to pinning is that we actively want to encourage 
>> packages to develop against the latest semantically appropriate versions of 
>> their dependencies, in order to foster rapid development amongst the 
>> ecosystem and strong reliance on the semantic versioning concept. Our design 
>> for version pinning is thus intended to be a feature for package authors and 
>> users to use in crafting specific workflows, not be a mechanism by which 
>> most of the packages in the ecosystem pin themselves to specific versions of 
>> each other.
>> 
>> Use Cases
>> 
>> Our proposal is designed to satisfy several different use cases for such a 
>> behavior:
>> 
>> Standardizing team workflows
>> 
>> When collaborating on a package, it can be valuable for team 

Re: [swift-evolution] [Discussion] API Guidelines

[William Sumner via swift-evolution]

> On Oct 14, 2016, at 8:49 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I’m still not convinced in some cases.
> 
> Take a look at UIViews and its method addSubview.
> 
> open func addSubview(_ view: UIView)
> Personally I’d change or write this function like so:
> 
> open func add(subview: UIView)
> This reduces unnecessary noise _ view for both the implementation and usage.
> 
> // Implementation
> open func add(subview: UIView) {
> // `subview` is descriptive and just fine here
> }
> 
> // Usage
> 
> self.view.add(subview: someOtherView)
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail

This conforms to the following rule from the Argument Labels section of the 
naming guidelines:

“[I]f the first argument forms part of a grammatical phrase, omit its label, 
appending any preceding words to the base name, e.g. x.addSubview(y)"

Preston___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private & fileprivate

[Daniel Duan via swift-evolution]

> On Oct 13, 2016, at 9:03 PM, Nevin Brackett-Rozinsky 
>  wrote:
> 
> Daniel, I would be interested to hear what, exactly, are the benefits your 
> project has realized from the new “private” compared to the old “private” 
> (which is now called “fileprivate”).
> 

There's no amazing insight here. The benefit is more granular control. The more 
people work on a project, the more useful this becomes.

You might as well ask "why not make everything public" if private and 
fileprivate makes no difference to you.

> Were there problems caused by the old “private” that have been solved by the 
> new “private”? Major problems? Minor annoyances?
> 
> • • •
> 
> As I see it, two significant drawbacks of the new “private” are increased 
> complexity in the access control model, and encumbrance of the old “private” 
> with the unwieldy moniker “fileprivate”.
> 

The first drawback is a truism: every language addition of feature makes it 
more complex. So we need to measure the benefit with other costs, which brings 
us to your second "drawback". I'm having a hard time understanding it. Is it 
too hard to type? If so, as an Objective-C survivor I disagree. The experience 
of reading code is harder and therefore more important than that of authoring 
code. "fileprivate" was chosen over many other alternatives because it's 
obvious to the reader. A shorter but equally obvious name would have been nice. 
But "unwieldy" is not enough reason to justify such source-breaking change at 
the moment.


> If the new “private” has brought real benefits sufficient to outweigh its 
> complexity cost then I think it should stay, and if not it should go. Thus I 
> am curious to see what benefits it has in practice.
> 
> • • •
> 
> Regardless of whether the new “private” is pulling its weight, I believe we 
> should find a shorter name for “fileprivate”.
> 
> And I think Xiaodi has the right idea: whensoever in the future we decide to 
> introduce submodules, it would be best if they subsumed the file scope. In 
> essence, a submodule would be the mechanism for parceling out code which 
> currently must reside in a single file (because it relies on “fileprivate” 
> which is the old “private”).
> 
> That way a submodule could comprise several interrelated pieces which need to 
> share privy details, while preserving their natural separation into distinct 
> files. So it makes sense that we should find a replacement for “fileprivate” 
> which is copacetic to submodules.
> 
> Actually, now that I write it down, I wonder if perhaps “privy” might work as 
> a keyword. It is short, it means “being party to shared secret knowledge”, 
> and its spelling conveys a sense of “private-ish”.
> 
> The other ideas I’ve come up with have shortcomings, such as “local” which 
> has a pre-existing incompatible meaning in programming (otherwise it would be 
> great), or “folio” which is not an adjective (and also isn’t ideal for the 
> single-file case).
> 
> But “privy” just might work.
> 
> Nevin
> 
> 
>> On Thu, Oct 13, 2016 at 10:44 PM, Daniel Duan via swift-evolution 
>>  wrote:
>> I question the practicality of "use private heavily simply because I don’t 
>> want the burden of mixing private and fileprivate". In our experience in 
>> converting a very mature Swift application, we had no choice but to use both 
>> because we wanted private as much as possible but that's too restrictive in 
>> some cases. The granularity private and fileprivate provide is definitey a 
>> welcome change.
>> 
>> Daniel Duan
>> Sent from my iPhone
>> 
>>> On Oct 13, 2016, at 3:11 AM, David Hart via swift-evolution 
>>>  wrote:
>>> 
>>> 
> On 13 Oct 2016, at 08:25, Jean-Daniel via swift-evolution 
>  wrote:
> 
> 
> Le 13 oct. 2016 à 07:52, Chris Lattner via swift-evolution 
>  a écrit :
> 
> On Oct 12, 2016, at 9:56 PM, Russ Bishop via swift-evolution 
>  wrote:
 I actually consider it very lucky that most of our changes so far have 
 been fairly non-controversial. Everybody has a different idea of what 
 would make Swift a better language, and all of us well-meaning. But 
 when those ideas conflict, some group is going to end up unhappy. I'm 
 actually very glad that (a) we haven't had too many of these cases, 
 and (b) even when we have, people have been able to accept it and move 
 on to contributing to the next issue.
>>> 
>>> 
>>> Strong agreement here as well. This proposal has been litigated 
>>> numerous times already, and the bar for source-breaking changes is much 
>>> higher now. To effectively re-open the discussion would require a 
>>> proposal that significant changes the model with a lot of evidence that 
>>> such a new model is a drastic improvement over what we have 

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

[Daniel Duan via swift-evolution]

Fyi, not my idea: 
https://github.com/apple/swift-evolution/commit/51d93875b25ba122a6417fdc5216ee94c6e7ee9e

Daniel Duan
Sent from my iPhone

> On Oct 14, 2016, at 7:14 AM, Goffredo Marocchi  wrote:
> 
> Let's not promote this idea English has comprehensible and easy to refer to 
> pronunciation rules ;). It needs reforming :P, but let's keep it for 
> English-Evolution ;).
> 
> Sent from my iPhone
> 
>> On 14 Oct 2016, at 13:42, Haravikk via swift-evolution 
>>  wrote:
>> 
>> 
>>> On 14 Oct 2016, at 07:16, Daniel Duan via swift-evolution 
>>>  wrote:
>>> 
>>> 1. “honor” is mis-spelled in “weird queen’s dialect”.
>> 
>> I'm sorry, but I throw an exception at this; when you say "weird queen's 
>> dialect" do you mean… English? I don't go around referring to the other 
>> variation as "weird can't spell dialect" (but maybe I should) 
>> The u in words like honour is what makes it pronounced like "onner" rather 
>> than "hone-ore", same with colour being "culler" rather than "coal-ore". 
>> Sorry but it really annoys me when people consider the English version of 
>> English to be the weird one, as the clue is literally in the name as to 
>> which version is correct. This is why it still galls me that the language in 
>> macOS is "British English" yet the other one is just "English" rather than 
>> "American English" or whatever, it's a hideous double standard.
>> 
>> 
>> That aside, I'm a strong +1 for the feature 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

Let's not promote this idea English has comprehensible and easy to refer to 
pronunciation rules ;). It needs reforming :P, but let's keep it for 
English-Evolution ;).

Sent from my iPhone

> On 14 Oct 2016, at 13:42, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 14 Oct 2016, at 07:16, Daniel Duan via swift-evolution 
>>  wrote:
>> 
>> 1. “honor” is mis-spelled in “weird queen’s dialect”.
> 
> I'm sorry, but I throw an exception at this; when you say "weird queen's 
> dialect" do you mean… English? I don't go around referring to the other 
> variation as "weird can't spell dialect" (but maybe I should) 
> The u in words like honour is what makes it pronounced like "onner" rather 
> than "hone-ore", same with colour being "culler" rather than "coal-ore". 
> Sorry but it really annoys me when people consider the English version of 
> English to be the weird one, as the clue is literally in the name as to which 
> version is correct. This is why it still galls me that the language in macOS 
> is "British English" yet the other one is just "English" rather than 
> "American English" or whatever, it's a hideous double standard.
> 
> 
> That aside, I'm a strong +1 for the feature 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] API Guidelines

[Adrian Zubarev via swift-evolution]

I’m still not convinced in some cases.

Take a look at UIViews and its method addSubview.

open func addSubview(_ view: UIView)
Personally I’d change or write this function like so:

open func add(subview: UIView)
This reduces unnecessary noise _ view for both the implementation and usage.

// Implementation
open func add(subview: UIView) {
// `subview` is descriptive and just fine here
}

// Usage

self.view.add(subview: someOtherView)


-- 
Adrian Zubarev
Sent with Airmail

Am 14. Oktober 2016 um 16:42:06, Zach Waldowski via swift-evolution 
(swift-evolution@swift.org) schrieb:

The base name of the function describes its core purpose.

There is no ambiguity instructing an Array to "append" something, but
there is context needed: "what are we appending? The contents of the
newElements parameter." But there is ambiguity asking URL to "give me a
new URL by appending". Appending what? Similarly, telling a collection
to "replace". Replace what?

A rule of thumb my team has applied is to put the parameter parens where
you would have put `with` in ObjC. This is instructive for your
questions as well. "URLByAppendingWithPathComponent" and
"replaceWithSubrange" wouldn't make sense, but "appendWithContentsOf"
does.

Cheers!
  Zachary Waldowski
  z...@waldowski.me

On Thu, Oct 13, 2016, at 10:30 PM, Charlie Monroe via swift-evolution
wrote:
> Hi there,
>  
> I am really grateful for the API guidelines that were created as part of
> Swift 3, however, I'm having trouble with distinguishing which part of
> the method name should be already an argument. To illustrate this, here
> are two examples:
>  
> // On Array
> public mutating func append(contentsOf newElements: S)
>  
> // On Foundation.URL
> public func appendingPathComponent(_ pathComponent: String) -> URL
>  
>  
> Is there a particular reason why it's not
>  
> public func appending(pathComponent: String) -> URL
>  
> ?
>  
> In my opinion the entire stdlib and Foundation is full of such
> discrepancies which make it hard to decide when you name your own methods
> since there are preceding cases in the language itself (or Foundation)
> that go both ways.
>  
> The same goes for why don't the replace methods (this is on String)
> follow the same - when there is append(contentsOf:):
>  
> public mutating func replaceSubrange(_ bounds: ClosedRange,
> with newElements: String)
>  
> instead of
>  
> public mutating func replace(subrange bounds: ClosedRange,
> with newElements: String)
>  
>  
>  
> I know there was an extensive discussion about this here when the stdlib
> names were discussed. And given that these would be breaking changes, I
> don't necessarily want to start a lengthy discussion about renaming those
> again - I'm just wondering what are the reasons behind this and what
> should be the correct naming conventions.
>  
> Thanks!
>  
> Charlie
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Benjamin Spratling via swift-evolution]

> Let's not promote this idea English has comprehensible and easy to refer to 
> pronunciation rules ;). It needs reforming :P, but let's keep it for 
> English-Evolution ;).


+1
  Can you get me on that list?  I have a long list of bugs to report. :)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private & fileprivate

[Jeremy Pereira via swift-evolution]

> On 14 Oct 2016, at 09:35, Jamie Lemon via swift-evolution 
>  wrote:
> 
> I agree with Ted that I would have expected the inner members of a class to 
> be private by default. (Not a big deal if I have to explicitly prefix most of 
> my concerned vars now - but it is just different to what I would have 
> expected). Certainly, in the past, I would be more used to having to 
> explicitly define chosen vars as “public” ( e.g. in the past world of 
> Objective C I  was used to defining selected vars with @synthesize to “open 
> them up" ) 

@synthesize has nothing to do with instance variable visibility, all it did was 
synthesise an instance variable to back a property (which  was really a pair of 
methods). In Objective-C instance variables are protected (i.e. visible to 
subclasses) by default and all methods (which by extension means properties 
too) are public. 

The waters are somewhat muddied by the fact that the Objective-C compiler can 
only see declarations in the current code unit and any imports, so you can hide 
non private instance variables by putting them in the @implementation and you 
can hide properties and methods by declaring them in a category that isn’t in 
an import. However, anybody can defeat the second of these by declaring their 
own category with the hidden method signatures in it.

private by default is comparatively rare, it’s not true of Java, C#, 
Javascript, or Python. Having said, that it does make sense to me but would be 
an enormous breaking change for Swift now.

I was against the private/fileprivate distinction when it was proposed, but now 
it’s done and I’ve applied it to my own code, I am fine with it. I did a global 
replace of fileprivate with private in one of my largest converted source files 
and experienced only one breakage. I think there is a use case for fileprivate, 
so I wouldn’t want to get rid of it but I think it’s rare enough that the 
ugliness of its name doesn’t bother me. 

> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] API Guidelines

[Zach Waldowski via swift-evolution]

The base name of the function describes its core purpose.

There is no ambiguity instructing an Array to "append" something, but
there is context needed: "what are we appending? The contents of the
newElements parameter." But there is ambiguity asking URL to "give me a
new URL by appending". Appending what? Similarly, telling a collection
to "replace". Replace what?

A rule of thumb my team has applied is to put the parameter parens where
you would have put `with` in ObjC. This is instructive for your
questions as well. "URLByAppendingWithPathComponent" and
"replaceWithSubrange" wouldn't make sense, but "appendWithContentsOf"
does.

Cheers!
  Zachary Waldowski
  z...@waldowski.me

On Thu, Oct 13, 2016, at 10:30 PM, Charlie Monroe via swift-evolution
wrote:
> Hi there,
> 
> I am really grateful for the API guidelines that were created as part of
> Swift 3, however, I'm having trouble with distinguishing which part of
> the method name should be already an argument. To illustrate this, here
> are two examples:
> 
> // On Array
> public mutating func append(contentsOf newElements: S)
> 
> // On Foundation.URL
> public func appendingPathComponent(_ pathComponent: String) -> URL
> 
> 
> Is there a particular reason why it's not
> 
> public func appending(pathComponent: String) -> URL
> 
> ?
> 
> In my opinion the entire stdlib and Foundation is full of such
> discrepancies which make it hard to decide when you name your own methods
> since there are preceding cases in the language itself (or Foundation)
> that go both ways.
> 
> The same goes for why don't the replace methods (this is on String)
> follow the same - when there is append(contentsOf:):
> 
> public mutating func replaceSubrange(_ bounds: ClosedRange,
> with newElements: String)
> 
> instead of
> 
> public mutating func replace(subrange bounds: ClosedRange,
> with newElements: String)
> 
> 
> 
> I know there was an extensive discussion about this here when the stdlib
> names were discussed. And given that these would be breaking changes, I
> don't necessarily want to start a lengthy discussion about renaming those
> again - I'm just wondering what are the reasons behind this and what
> should be the correct naming conventions.
> 
> Thanks!
> 
> Charlie
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Alexis Beingessner via swift-evolution]

> On Oct 14, 2016, at 8:00 PM, Paul Cantrell  wrote:
> 
> 
>>> On Oct 14, 2016, at 6:42 PM, Daniel Dunbar  wrote:
>>> 
>>> On Oct 14, 2016, at 4:02 PM, Paul Cantrell  wrote:
>>> 
>>> I’m puzzled. If a package’s pinning does not affect any other package that 
>>> uses it, why should the defaults be different? A library will still suffer 
>>> from all the “works for me” problems an app might.
>>> 
>>> Is the rationale that not pinning libraries encourages accidental testing 
>>> of new versions of a library’s dependencies as they arrive? Or is there 
>>> another rationale for having different defaults?
>> 
>> I'll defer to this comment (linked from someone else earlier in the thread), 
>> which happens to match up with my perspective:
>> https://github.com/yarnpkg/yarn/issues/838#issuecomment-253362537
> 
> I took that comment to be an explanation of why a library's lockfile/pinfile 
> should not propagate to other packages that use it. That is clearly the case; 
> such pin propagation would be nonsensical.
> 
> My question was not about that, but about why libraries shouldn’t use a 
> pinfile at all, even for their own _internal_ development. All the same “last 
> know good build” concerns apply.
> 
> The difference is that testing against that single last known good version 
> set is sufficient for a top-level package, whereas a library should (1) 
> ideally test against multiple valid dependency versions and (2) test often 
> against new versions of its dependencies. I don’t see, however, that this 
> implies that libraries should not have pinfiles at all — just that their 
> release / CI process should not be limited to what’s pinned.

A few comments down, Yehuda even provides an example of him doing just that 
with Bundler:

https://github.com/yarnpkg/yarn/issues/838#issuecomment-253366352

But in this case you actually want to maintain *many* lock files, and so it 
seems fine to require a bit of extra work (passing some flags) to do this. 
Drifting tests are the better default here. It makes library CI into an 
alpha-tester, empowering binaries to be more confident in upgrading frequently.

> 
> Cheers, P
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Daniel Dunbar via swift-evolution]

> 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 the defaults be different? A library will still suffer 
>>> from all the “works for me” problems an app might.
>>> 
>>> Is the rationale that not pinning libraries encourages accidental testing 
>>> of new versions of a library’s dependencies as they arrive?
>> 
>> Yep.
> 
> I’m skeptical of whether disabling pinning by default is the right answer. It 
> seems … haphazard and incomplete, likely to confuse those who don’t 
> understand this reasoning, and only incidentally helpful to those who do.
> 
> I’d prefer an approach that is more mindful, more intentional.
> 
> Emitting warnings when newer versions of packages are available would help 
> address the same issue. This would also encourage apps to get security 
> patches promptly.
> 
> A more ambitious approach might be to provide a utility that installs and 
> tests various combinations of all the semantically allowed versions of a 
> lib’s dependencies — at the very least, all the lowest and highest allowed 
> versions. This would ignore any existing pinfile. Library devs would run this 
> prior to release, and on a CI server if they have one.
> 
> This would have the advantage of catching incompatibilities with _past_ 
> versions of libraries as well as _new_ ones. In particular, it would catch 
> too-permissive version specifications, e.g. if your library asks for foolib 
> 3.x but relies on a bugfix in 3.4.2, this approach would catch that problem.
> 
> That’s clearly a bigger, separate idea, not necessary to hash out right now. 
> I mean it just to illustrate what better approaches might look like. I’m 
> skeptical that simply disabling pinning does a good job of solving the 
> intended problem, and don’t think it should weigh quite so heavily on the 
> proposal at hand.

The current idea wouldn't "disable it", it would discourage you from checking 
it in for a library (it really comes down to you have to run two commands, not 
one). I agree all the other things you outline are useful, and that not 
checking it in doesn't magically solve the problem here.

 - Daniel

> 
> Cheers,
> 
> Paul
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.swift.org_mailman_listinfo_swift-2Devolution=CwIGaQ=Hw-EJUFt2_D9PK5csBJ29kRV40HqSDXWTLPyZ6W8u84=teZCCTj9bCvNJ4SX_xKQ4SOVlaMWK9IXMlx_HMapKUU=wl9y8ecLDwSW83LjsOje4Jz1_TjqamVYnv-lTnVooiI=ICIfe-G4A6ZgJyiYYtMnHpq6JKQpHA5nhxc8nG4GxhY=
>  

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Daniel Müllenborn via swift-evolution]

* What is your evaluation of the proposal?
-1
* Does this proposal fit well with the feel and direction of Swift?
Not at all.
* How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?
Not much, as it just does not appeal to me.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Paul Cantrell via swift-evolution]

> On Oct 14, 2016, at 7:18 PM, Daniel Dunbar  wrote:
> 
>> 
>> On Oct 14, 2016, at 4:51 PM, Paul Cantrell via swift-evolution 
>>  wrote:
>> 
>> That’s clearly a bigger, separate idea, not necessary to hash out right now. 
>> I mean it just to illustrate what better approaches might look like. I’m 
>> skeptical that simply disabling pinning does a good job of solving the 
>> intended problem, and don’t think it should weigh quite so heavily on the 
>> proposal at hand.
> 
> The current idea wouldn't "disable it”

Right, my bad wording. Is “turn off / discourage pinfiles by default for 
libraries but not apps” a better description of the general idea?

> it would discourage you from checking it in for a library (it really comes 
> down to you have to run two commands, not one). I agree all the other things 
> you outline are useful, and that not checking it in doesn't magically solve 
> the problem here.


If the difference were only what’s in .gitignore, I’d be completely comfortable 
with that. Enthusiastic.

And if there’s some distinction between libs and top-level packages that only 
affects a generated .gitignore and/or emitted warnings, I’d be completely 
comfortable with that.

I’m skeptical of deeper special-casing for libs vs. top-level, but it sounds 
like the special-casing may not actually be that deep. If so, I’m just fussing 
over nothing!

> On Oct 14, 2016, at 7:17 PM, Alexis Beingessner  
> wrote:
> 
> A few comments down, Yehuda even provides an example of him doing just that 
> with Bundler:
> 
> https://github.com/yarnpkg/yarn/issues/838#issuecomment-253366352 
> 
Yeah, I’d love to see SwiftPM or a companion tool automate that. Totally 
tractable problem, and I’ll bet we see quality payoffs in the lib ecosystem.

Cheers,

Paul

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal Draft] Provide Custom Collections for Dictionary Keys and Values

[Paul Cantrell via swift-evolution]

A late-arriving strong +1 for me. The index-related stuff is elegant and much 
needed. I’m surprised to learn that dict.keys and dict.values are copies and 
not already views! Clearly they should be.

Question: I hit a closely related performance wall just last week, doing 
something like this:

for k in dict.keys {
dict.values[k].append(1)
}

I assume / hope the proposal would also support this?

for i in dict.indices {
dict.values[i].append(1)
}

…or would it be this?

for i in dict.keys.indices {
dict.values[i].append(1)
}

…or either?

Cheers, P



> On Oct 11, 2016, at 4:28 PM, Nate Cook via swift-evolution 
>  wrote:
> 
> Introduction
> 
> This proposal addresses significant unexpected performance gaps when using 
> dictionaries. It introduces type-specific collections for a Dictionary 
> instance's keys and values properties.
> 
> New DictionaryKeys and DictionaryValues collections provide efficient key 
> lookup and mutable access to dictionary values, enabling updates to be 
> performed in-place and allowing copy-on-write optimization of stored values.
> 
>  
> Motivation
> 
> This proposal address two problems:
> 
> The Dictionary type keys implementation is inefficient, because 
> LazyMapCollection doesn't know how to forward lookups to the underlying 
> dictionary storage.
> Dictionaries do not offer value-mutating APIs. The mutating key-based 
> subscript wraps values in an Optional. This prevents types with copy-on-write 
> optimizations from recognizing they are singly referenced.
> This proposal uses the following [String: [Int]] dictionary to demonstrate 
> these problems:
> 
> var dict = ["one": [1], "two": [2, 2], "three": [3, 3, 3]]
>  
> Inefficient
>  dict.keys Search
> 
> Swift coders normally test key membership using nil checks or underscored 
> optional bindings:
> 
> if dict["one"] != nil {
> // ...
> }
> if let _ = dict["one"] {
> // ...
> }
> These approaches provide the expected performance of a dictionary lookup but 
> they read neither well nor "Swifty". Checking keys reads much better but 
> introduces a serious performance penalty: this approach requires a linear 
> search through a dictionary's keys to find a match.
> 
> if dict.keys.contains("one") {
> // ...
> }
> A similar dynamic plays out when comparing dict.index(forKey:) and 
> dict.keys.index(of:).
> 
>  
> Inefficient
>  Value Mutation
> 
> Dictionary values can be modified through the keyed subscript by direct 
> reassignment or by using optional chaining. Both of these statements append 1 
> to the array stored by the key "one":
> 
> // Direct re-assignment
> dict["one"] = (dict["one"] ?? []) + [1]
> 
> // Optional chaining
> dict["one"]?.append(1)
> Both approaches present problems. The first is complex and hard to read. The 
> second ignores the case where "one" is not a key in the dictionary. It forces 
> its check into a higher branch and encourages forced unwrapping. Furthermore, 
> neither approach allows the array to grow in place. They introduce an 
> unnecessary copy of the array's contents even though dict is the sole holder 
> of its storage.
> 
> Adding mutation to a dictionary's index-based subscripting isn't possible. 
> Changing a key stored at a particular index would almost certainly modify its 
> hash value, rendering the index incorrect. This violates the requirements of 
> the MutableCollection protocol.
> 
>  
> Proposed
>  Solution
> 
> This proposal adds a custom collection for the keys and values dictionary 
> properties. This follows the example set by String, which presents multiple 
> views of its contents. A new DictionaryKeys collection introduces efficient 
> key lookup, while a new DictionaryValues collection provides a mutable 
> collection interface to dictionary values.
> 
> These changes introduce a simple and efficient way of checking whether a 
> dictionary includes a key:
> 
> // Performant
> if dict.keys.contains("one") {
> // ...
> }
> As a mutable collection, values enables modification without copies or clumsy 
> code:
> 
> if let i = dict.index(forKey: "one") {
> dict.values[i].append(1)  // no copy here
> } else {
> dict["one"] = [1]
> }
> Both the keys and values collections share the same index type as Dictionary. 
> This allows the above sample to be rewritten as:
> 
> // Using `dict.keys.index(of:)`
> if let i = dict.keys.index(of: "one") {
> dict.values[i].append(1)
> } else {
> dict["one"] = [1]
> }
>  
> 

Re: [swift-evolution] stored properties in extensions (was: associated objects)

[Paul Cantrell via swift-evolution]

> On Oct 9, 2016, at 3:43 PM, Charles Srstka via swift-evolution 
>  wrote:
> 
> Let extensions introduce stored properties, but only in the same module as 
> the type’s definition. Then, the compiler can just take any extensions into 
> consideration when it’s determining the size of the type, just as if the 
> properties had been declared in the type. Declaring stored properties on an 
> extension outside of the type’s module results in a compiler error, exactly 
> as today. This would, without any performance drawbacks, solve one of the big 
> problems that people are hoping to solve via stored properties in 
> extensions—the ability to organize members by protocol conformance.

Yes please! A big strong +1 to this from me. I can think of several specific 
chunks of problem code that this would clean up immensely.

Contra Karl in another message, it’s _in-module_ stored property extensions 
that I want most frequently. By far.

It seems to me that Charles’s idea could be introduced as its own proposal. If 
out-of-module stored property extensions do eventually become feasible, then 
Charles’s proposal is a good stepping stone. If they never do, then his 
proposal has done no harm.

I realize this probably falls into the post-ABI stability bucket, but I’d love 
to help write/support the proposal when its time comes.

Cheers,

Paul

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Alex Martini via swift-evolution]

> On Oct 14, 2016, at 1:53 PM, Hooman Mehr via swift-evolution 
>  wrote:
> 
>> On Oct 14, 2016, at 1:49 PM, Daniel Duan via swift-evolution 
>> > wrote:
>> 
>> Agree with Robert here. I'd rather be able to use it as part of operators. 
>> Currently the character set for operators and identifier head are mutually 
>> exclusive. So this proposal will remove that possibility. This deserves some 
>> discussion.
>> 
>> Daniel Duan
>> Sent from my iPhone
> 

> I don’t think $ will be become available to be used as an operator if we 
> remove its identifier use. 


If $ is an operator, then "$2" looks like the custom unary prefix operator "$" 
applied to "2".  That's a problem; it needs to be parsed as the identifier "$2" 
instead.

We could prevent "$" from being allowed a prefix operator.  There is precedent 
for the language reserving operators that would otherwise be allowed, such as 
postfix "?" and postfix "!".

-- Alex___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Richard Wei via swift-evolution]

> * What is your evaluation of the proposal?
-1. If it were a valid identifier, $ would look even more confusing when used 
as a type name. I’d rather see $ used as an operator. 

> * 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?
No.

> * If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?
I don’t think this is a Swifty style.

> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
More than a quick reading.

-Richard

> On Oct 14, 2016, at 14:59, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0144: Allow Single Dollar Sign as a Valid Identifier" 
> begins now and runs through October 18. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to 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
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Eloy Durán via swift-evolution]

> I’m puzzled. If a package’s pinning does not affect any other package that 
> uses it, why should the defaults be different? A library will still suffer 
> from all the “works for me” problems an app might.
> 
> Is the rationale that not pinning libraries encourages accidental testing of 
> new versions of a library’s dependencies as they arrive?

Yep.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Proposal: Package Manager Version Pinning

[Ankit Aggarwal via swift-evolution]

Hi,

We're proposing version pinning feature in Swift Package Manager. The proposal 
is available here 

 and also in this email:

Feedback welcomed!

Thanks,
Ankit



Package Manager Version Pinning
Proposal: SE-
Author: Daniel Dunbar , Ankit Aggarwal 

Review Manager: TBD
Status: Discussion
Introduction
This is a proposal for adding package manager features to "pin" or "lock" 
package dependencies to particular versions.

Motivation
As used in this proposal, version pinning refers to the practice of controlling 
exactly which specific version of a dependency is selected by the dependency 
resolution algorithm, independent from the semantic versioning specification. 
Thus, it is a way of instructing the package manager to select a particular 
version from among all of the versions of a package which could be chosen while 
honoring the dependency constraints.

Terminology

We have chosen to use "pinning" to refer to this feature, over "lockfiles", 
since the term "lock" is already overloaded between POSIX file locks and locks 
in concurrent programming.

Philosophy

Our philosophy with regard to pinning is that we actively want to encourage 
packages to develop against the latest semantically appropriate versions of 
their dependencies, in order to foster rapid development amongst the ecosystem 
and strong reliance on the semantic versioning concept. Our design for version 
pinning is thus intended to be a feature for package authors and users to use 
in crafting specific workflows, not be a mechanism by which most of the 
packages in the ecosystem pin themselves to specific versions of each other.

Use Cases

Our proposal is designed to satisfy several different use cases for such a 
behavior:

Standardizing team workflows

When collaborating on a package, it can be valuable for team members (and 
continuous integration) to all know they are using the same exact version of 
dependencies, to avoid "works for me" situations.

This can be particularly important for certain kinds of open source projects 
which are actively being cloned by new users, and which want to have some 
measure of control around exactly which available version of a dependency is 
selected.

Difficult to test packages or dependencies

Complex packages which have dependencies which may be hard to test, or hard to 
analyze when they break, may choose to maintain careful control over what 
versions of their upstream dependencies they recommend -- even if conceptually 
they regularly update those recommendations following the true semantic version 
specification of the dependency.

Dependency locking w.r.t. deployment

When stabilizing a release for deployment, or building a version of a package 
for deployment, it is important to be able to lock down the exact versions of 
dependencies in use, so that the resulting product can be exactly recreated 
later if necessary.

Proposed solution
We will introduce support for an optional new file Package.pins adjacent to the 
Package.swift manifest, called the "pins file". We will also introduce a number 
of new commands (see below) for maintaining the pins file.

This file will record the active version pin information for the package, 
including data such as the package identifier, the pinned version, and explicit 
information on the pinned version (e.g., the commit hash/SHA for the resolved 
tag).

The exact file format is unspecified/implementation defined, however, in 
practice it will be a JSON data file.

This file may be checked into SCM by the user, so that its effects apply to all 
users of the package. However, it may also be maintained only locally (e.g., 
placed in the .gitignore file). We intend to leave it to package authors to 
decide which use case is best for their project.

In the presence of a Package.pins file, the package manager will respect the 
pinned dependencies recorded in the file whenever it needs to do dependency 
resolution (e.g., on the initial checkout or when updating).

The pins file will not override Manifest specified version requirements and it 
will be an error (with proper diagnostics) if there is a conflict between the 
pins and the manifest specification.

Detailed Design
We will add a new command pin to swift package tool with following semantics:

$ swift package pin ( [--all] | [] [] ) [--message 
]
The package-name refers to the name of the package as specified in its manifest.

This command pins one or all dependencies. The command which pins a single 
version can optionally take a specific version to pin to, if unspecified (or 
with --all) the behaviour is to pin to the current package version in use. 
Examples: 

$ swift package pin --all - pins all the dependencies.
$ swift package pin Foo - pins Foo at current resolved version.
$ swift package pin Foo 1.2.3 - pins Foo at 

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

[Daniel Duan via swift-evolution]

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 dialect”.
2. SHA/man-in-the-middle attack section needs either more detailed 
explanation/reference materials, or shouldn’t be included at all (assuming when 
the hash feature gets introduced, there’d be another proposal for it).

Overall strong +1.
> On Oct 13, 2016, at 11:01 PM, Ankit Aggarwal via swift-evolution 
>  wrote:
> 
> Hi,
> 
> We're proposing version pinning feature in Swift Package Manager. The 
> proposal is available here 
> 
>  and also in this email:
> 
> Feedback welcomed!
> 
> Thanks,
> Ankit
> 
> 
> 
> Package Manager Version Pinning
> Proposal: SE-
> Author: Daniel Dunbar , Ankit Aggarwal 
> 
> Review Manager: TBD
> Status: Discussion
> Introduction
> This is a proposal for adding package manager features to "pin" or "lock" 
> package dependencies to particular versions.
> 
> Motivation
> As used in this proposal, version pinning refers to the practice of 
> controlling exactly which specific version of a dependency is selected by the 
> dependency resolution algorithm, independent from the semantic versioning 
> specification. Thus, it is a way of instructing the package manager to select 
> a particular version from among all of the versions of a package which could 
> be chosen while honoring the dependency constraints.
> 
> Terminology
> 
> We have chosen to use "pinning" to refer to this feature, over "lockfiles", 
> since the term "lock" is already overloaded between POSIX file locks and 
> locks in concurrent programming.
> 
> Philosophy
> 
> Our philosophy with regard to pinning is that we actively want to encourage 
> packages to develop against the latest semantically appropriate versions of 
> their dependencies, in order to foster rapid development amongst the 
> ecosystem and strong reliance on the semantic versioning concept. Our design 
> for version pinning is thus intended to be a feature for package authors and 
> users to use in crafting specific workflows, not be a mechanism by which most 
> of the packages in the ecosystem pin themselves to specific versions of each 
> other.
> 
> Use Cases
> 
> Our proposal is designed to satisfy several different use cases for such a 
> behavior:
> 
> Standardizing team workflows
> 
> When collaborating on a package, it can be valuable for team members (and 
> continuous integration) to all know they are using the same exact version of 
> dependencies, to avoid "works for me" situations.
> 
> This can be particularly important for certain kinds of open source projects 
> which are actively being cloned by new users, and which want to have some 
> measure of control around exactly which available version of a dependency is 
> selected.
> 
> Difficult to test packages or dependencies
> 
> Complex packages which have dependencies which may be hard to test, or hard 
> to analyze when they break, may choose to maintain careful control over what 
> versions of their upstream dependencies they recommend -- even if 
> conceptually they regularly update those recommendations following the true 
> semantic version specification of the dependency.
> 
> Dependency locking w.r.t. deployment
> 
> When stabilizing a release for deployment, or building a version of a package 
> for deployment, it is important to be able to lock down the exact versions of 
> dependencies in use, so that the resulting product can be exactly recreated 
> later if necessary.
> 
> Proposed solution
> We will introduce support for an optional new file Package.pins adjacent to 
> the Package.swift manifest, called the "pins file". We will also introduce a 
> number of new commands (see below) for maintaining the pins file.
> 
> This file will record the active version pin information for the package, 
> including data such as the package identifier, the pinned version, and 
> explicit information on the pinned version (e.g., the commit hash/SHA for the 
> resolved tag).
> 
> The exact file format is unspecified/implementation defined, however, in 
> practice it will be a JSON data file.
> 
> This file may be checked into SCM by the user, so that its effects apply to 
> all users of the package. However, it may also be maintained only locally 
> (e.g., placed in the .gitignore file). We intend to leave it to package 
> authors to decide which use case is best for their project.
> 
> In the presence of a Package.pins file, the package manager will respect the 
> pinned dependencies recorded in the file whenever it needs to do dependency 
> resolution (e.g., on the initial checkout or when updating).
> 
> The pins file will not override Manifest specified version requirements and 
> it will be an 

Re: [swift-evolution] [Proposal Draft] Provide Custom Collections for Dictionary Keys and Values

[Nate Cook via swift-evolution]

> On Oct 13, 2016, at 1:28 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> on Wed Oct 12 2016, Nate Cook  > wrote:
> 
>>> On Oct 12, 2016, at 9:32 AM, plx via swift-evolution 
>>>  wrote:
>>> 
>>> The issue addressed is real; I’m not sure this is the best approach. 
>>> 
>>> In particular, unless I’m missing something obvious, the ownership strategy 
>>> here would have to be:
>>> 
>>> - `DictionaryKeys` and `DictionaryValues` would each induce the expected +1 
>>> retain on the
>> underlying storage
>>> - `DictionaryValues`’s mutations avoid triggering COW on the underlying 
>>> storage by skipping the
>> usual ownership check
>>> 
>>> …as otherwise it’s unclear how you’d do those in-place mutations
>>> (and this seems to be how the implementation works...is that
>>> correct?).
>> 
>> That's not quite right—when you access these views through the
>> dictionary, they do not increment the storage retain count. This is
>> the way slicing and views currently work on other mutable types. For
>> example, when you reverse a slice of an array in-place, the slice
>> doesn't get its own duplicate storage:
>> 
>> var a = Array(1...10)
>> a[0..<5].reverse()
>> a == [5, 4, 3, 2, 1, 6, 7, 8, 9, 10]
> 
> Oh, yes it certainly does.  This is currently inefficient because
> pinning is tied to addressors and addressors can only return pointers to
> things that actually exist in memory somewhere.  The slice doesn't.

Ack, sorry everyone! Listen to Dave. 

I got carried away with examples that went further than my proposal. As far as 
I can tell from my testing, the examples in the proposal are still accurate.

>> However, if you create a new variable out of the slice and reverse that, the 
>> slice does get its own
>> storage:
>> 
>> var b = Array(1...10)
>> var bSlice = b[0..<5]
>> bSlice.reverse()
>> bSlice == [5, 4, 3, 2, 1]
>> b == [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
> 
> This doesn't demonstrate anything; you're just showing the effects of
> value semantics.  If you go
> 
> b[0..<5] = bSlice
> 
> you'll then have
> 
> b == [5, 4, 3, 2, 1, 6, 7, 8, 9, 10]
> 
> And that is exactly what happens in the first example.
> 
> This is a major flaw that prevents Swift's collection model from being
> fully general and efficient.  I think we will be fixing it, by fixing
> the way inout works, as a consequence of the work on ownership, for
> Swift 4.  But as noted elsewhere, that's a wild-ass guess at the moment.
> 
>> Strings and their views work the same way:
>> 
>> var s = "abcdefg"
>> s.characters.append("H")   // storage updated in place
>> s == "abcdefgH"
>> 
>> var sChars = s.characters  // no copy yet
>> sChars.removeLast() // sChars gets its own copy before the mutation
>> s == "abcdefgH"
>> String(sChars) == "abcdefg"
>> 
>> var t = s   // no copy yet
>> t.characters.removeLast()  // t gets a new copy here
>> s == "abcdefgH"
>> t == "abcdefg"
>> 
>> I don't know the name of the compiler feature that enables this, but
>> it's a critical part of the way views and slices work.
> 
> I wish :-)



>>> With that design, it seems like you’d wind up allowing things like the 
>>> below:
>>> 
>>>  // example A
>>>  let foo = [ “abc”: [1,2,3], “efg”: [4,5,6] ]
>>>  let bar = foo // shared storage, no COW
>>>  foo.values[foo.index(of: “abc”)!].append(789) // update shared storage, no 
>>> COW
>>> 
>>>  // shared storage mutated,
>>>  // despite (a) both being `let` and (b) only foo.values getting touched
>>>  foo[“abc”] // [1, 2, 3, 789]
>>>  bar[“abc”] // [1, 2, 3, 789]
>> 
>> Example A isn't allowed—if foo and bar are both immutable, both of
>> their `values` collections are also immutable, so there's no way to
>> modify their shared storage.
>> 
>>>  // example B
>>>  var foo = [ “abc”: [1,2,3], “efg”: [4,5,6] ]
>>>  var bar = foo // shared storage, no COW
>>>  foo.values[foo.index(of: “abc”)!].append(789)
>>> 
>>>  // shared storage mutated only foo.values getting touched
>>>  foo[“abc”] // [1, 2, 3, 789]
>>>  bar[“abc”] // [1, 2, 3, 789]
>> 
>> Example B is incorrect—the mutation at `foo.values[...].append(789)`
>> triggers a copy of the entire dictionary's underlying storage before
>> allowing the mutation, since it knows that storage isn't uniquely
>> referenced.
>> 
>>>  // example C
>>>  var foo = [ “abc”: [1,2,3], “efg”: [4,5,6] ]
>>>  var bar = foo 
>>>  bar[“abc”] = [1, 2, 3, 4] // COW triggered here, no shared storage
>>>  foo.values[foo.index(of: “abc”)!].append(789)
>>> 
>>>  // only `foo`’s storage mutated, b/c change to `bar` triggered COW
>>>  foo[“abc”] // [1, 2, 3, 789]
>>>  bar[“abc”] // [1, 2, 3, 4]
>> 
>> This is the current behavior and would remain the same after the proposed 
>> the changes.
>> 
>>> …where both A (by itself) and the B/C contrast seem very unwelcome.
>>> 
>>> Also, even if we assume we only ever make *responsible* use, having
>>> the stdlib include such directly-mutating 

Re: [swift-evolution] private & fileprivate

[Rien via swift-evolution]

> On 14 Oct 2016, at 06:03, Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> 
> Daniel, I would be interested to hear what, exactly, are the benefits your 
> project has realized from the new “private” compared to the old “private” 
> (which is now called “fileprivate”).
> 
> Were there problems caused by the old “private” that have been solved by the 
> new “private”? Major problems? Minor annoyances?
> 

Yes please.
To me, access levels seem to be more about communication than about problem 
solving. I.e. if I make something ‘private’ then I am communicating to the 
outside world “hey don’t touch this”. And if it ain’t private then “go ahead, 
change this any way you like”. But imo they don’t solve an actual programming 
problem. No?

Rien



> • • •
> 
> As I see it, two significant drawbacks of the new “private” are increased 
> complexity in the access control model, and encumbrance of the old “private” 
> with the unwieldy moniker “fileprivate”.
> 
> If the new “private” has brought real benefits sufficient to outweigh its 
> complexity cost then I think it should stay, and if not it should go. Thus I 
> am curious to see what benefits it has in practice.
> 
> • • •
> 
> Regardless of whether the new “private” is pulling its weight, I believe we 
> should find a shorter name for “fileprivate”.
> 
> And I think Xiaodi has the right idea: whensoever in the future we decide to 
> introduce submodules, it would be best if they subsumed the file scope. In 
> essence, a submodule would be the mechanism for parceling out code which 
> currently must reside in a single file (because it relies on “fileprivate” 
> which is the old “private”).
> 
> That way a submodule could comprise several interrelated pieces which need to 
> share privy details, while preserving their natural separation into distinct 
> files. So it makes sense that we should find a replacement for “fileprivate” 
> which is copacetic to submodules.
> 
> Actually, now that I write it down, I wonder if perhaps “privy” might work as 
> a keyword. It is short, it means “being party to shared secret knowledge”, 
> and its spelling conveys a sense of “private-ish”.
> 
> The other ideas I’ve come up with have shortcomings, such as “local” which 
> has a pre-existing incompatible meaning in programming (otherwise it would be 
> great), or “folio” which is not an adjective (and also isn’t ideal for the 
> single-file case).
> 
> But “privy” just might work.
> 
> Nevin
> 
> 
> On Thu, Oct 13, 2016 at 10:44 PM, Daniel Duan via swift-evolution 
>  wrote:
> I question the practicality of "use private heavily simply because I don’t 
> want the burden of mixing private and fileprivate". In our experience in 
> converting a very mature Swift application, we had no choice but to use both 
> because we wanted private as much as possible but that's too restrictive in 
> some cases. The granularity private and fileprivate provide is definitey a 
> welcome change.
> 
> Daniel Duan
> Sent from my iPhone
> 
> On Oct 13, 2016, at 3:11 AM, David Hart via swift-evolution 
>  wrote:
> 
>> 
>>> On 13 Oct 2016, at 08:25, Jean-Daniel via swift-evolution 
>>>  wrote:
>>> 
>>> 
 Le 13 oct. 2016 à 07:52, Chris Lattner via swift-evolution 
  a écrit :
 
 On Oct 12, 2016, at 9:56 PM, Russ Bishop via swift-evolution 
  wrote:
>>> I actually consider it very lucky that most of our changes so far have 
>>> been fairly non-controversial. Everybody has a different idea of what 
>>> would make Swift a better language, and all of us well-meaning. But 
>>> when those ideas conflict, some group is going to end up unhappy. I'm 
>>> actually very glad that (a) we haven't had too many of these cases, and 
>>> (b) even when we have, people have been able to accept it and move on 
>>> to contributing to the next issue.
>> 
>> Strong agreement here as well. This proposal has been litigated numerous 
>> times already, and the bar for source-breaking changes is much higher 
>> now. To effectively re-open the discussion would require a proposal that 
>> significant changes the model with a lot of evidence that such a new 
>> model is a drastic improvement over what we have now. “Back out SE-0025” 
>> is not a viable option now.
>> 
>>  - Doug
> 
> Not really. This proposal could be backed out without source-breaking 
> changes by treating private as a synonym for fileprivate and we’d have 
> Swift 2 behavior without breaking source. If the core team doesn’t want 
> to consider that then we can just move on and live with it. 
 
 Not speaking for the core team, just MHO:
 
 I agree with Russ here, and with others who have said upthread that the 
 “thing that has changed” is that we are starting to get 

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

[Daniel Dunbar via swift-evolution]

> 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 JavaScript/Rust/iOS with CocoaPods and then switching to 
> Swift, would require a lot of unneeded context switching, as in: "Where's 
> that lockfile? I can't find it. Oh great, turns out it's not a lockfile, it's 
> something else".

In Swift, we have pretty consistently tried to choose the "right" answer to 
make the resulting language consistent and beautiful.

I'm perfectly happy to have a discussion about the naming, but I would like it 
to be driven by what we believe the "right" answer is, not simply by deference 
to existing solutions. I do sympathize with wanting to be consistent where 
there is little value in diverging, but most people I have discussed this with 
agree that "lock" is actually the *wrong* word to use for this operation.

Also, please be mindful that your perspective is biased by the tools you are 
familiar with. Python's pip tool, for example, uses "freeze" for this, and 
Heroku expects "requirements.txt", so someone coming from that ecosystem could 
make the same argument in another direction. I find arguments about "A does X 
so we should do X" most compelling when it comes with a relatively complete 
survey of existing tools. not just a particular slice of possible tools.

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 the connotation actually works 
fairly well (e.g., a pinboard is something you pin to while working, or pinning 
a dress while you stitch it). I also wasn't a huge fan of pin initially, but as 
it bounced around in my head for a while I really started to like it, for 
exactly this connotation reason.

 - Daniel

> 
> With best regards, Max.
> 
>> On 14 Oct 2016, at 17:59, Max Desiatov > > wrote:
>> 
>> I also agree with the point that .lock extension better suits here and 
>> adheres to a convention already established in other languages. I personally 
>> would prefer the file to be named Package.lock, not Package.pins and also 
>> think that it would help newcomers who already used other package managers, 
>> especially CocoaPods.
>> 
>> With best regards, Max.
>> 
>>> On 14 Oct 2016, at 17:43, 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 feature in Swift Package Manager. The 
 proposal is available here 
 
  and also in this email:
 
 Feedback welcomed!
 
 Thanks,
 Ankit
 
 
 
 Package Manager Version Pinning
 Proposal: SE-
 Author: Daniel Dunbar , Ankit Aggarwal 
 
 Review Manager: TBD
 Status: Discussion
 Introduction
 This is a proposal for adding package manager features to "pin" or "lock" 
 package dependencies to particular versions.
 
 Motivation
 As used in this proposal, version pinning refers to the practice of 
 controlling exactly which specific version of a dependency is selected by 
 the dependency resolution algorithm, independent from the semantic 
 versioning specification. Thus, it is a way of instructing the package 
 manager to select a particular version from among all of the versions of a 
 package which could be chosen while honoring the dependency constraints.
 
 Terminology
 
 We have chosen to use "pinning" to refer to this feature, over 
 "lockfiles", since the term "lock" is already overloaded between POSIX 
 file locks and locks in concurrent programming.
 
>>> I’ve never seen this cause any actual confusion, nor has anyone I know who 
>>> teaches/develops these sorts of tools. As far as I can tell, the broader 
>>> programming community is rapidly converging on this as standard terminology:
>>> 
>>> * Gemfile.lock (Ruby)
>>> * Cargo.lock (Rust)
>>> * Composer.lock (PHP)
>>> * yarn.lock (JS)
>>> * pubspec.lock (Dart)
>>> * Podfile.lock (Swift/Objc!)
>>> 
>>> Diverging from this seems counter-productive.
 Philosophy
 
 Our philosophy with regard to pinning is that we actively want to 
 encourage packages to develop against the latest semantically appropriate 
 versions of their dependencies, in order to foster rapid development 
 amongst the 

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

[orta therox via swift-evolution]

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 seems unreasonable. Updates 
to code ships bugs. Updates you don’t expect gives you bugs you didn’t expect.

Alexis hits it on the head with the differentiation between a library and an 
app - libraries should define their own supported ranges, and they require far 
less locking than applications. An application should always have a lock so you 
have determinate builds and can update dependencies on purpose.

> We generally agree that when you are simply the consumer of packages, pinning 
> makes sense.

Isn’t this going to be the majority of the behaviour for the tool on the long 
run? So I would expect that to be where locking happens.

Sidenote: FWIW not a fan of the name change from lockfile - it feels arbitrary, 
but I figured the change to a separate command was a bigger elephant in the 
room.

-- 

[A.]Orta Therox

> w/ Artsy CocoaPods  / CocoaDocs 
>  / GIFs.app 
> 
> @orta  / orta.github.com 
> On 14 Oct 2016, at 17:43, Daniel Dunbar  wrote:
> 
> 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 command as it will make builds 
>> reproducible by default. 
>> 
>> I totally agree that we can rely on past experience with other package 
>> managers (npm being the case), where pinning with a separate command caused 
>> more harm than good.
>> 
>> Overall, I think that it would be great if Package.lock was created by 
>> default when it's not present and be updated only with an explicit command 
>> for updating.
>> 
>> With best regards, Max.
>> 
>> 
>>> On 14 Oct 2016, at 08:29, orta therox via swift-build-dev 
>>> > wrote:
>>> 
>>> Please don’t make this a separate command, it should ideally be created at 
>>> the end of an build (when there isn’t one already) or an update of your 
>>> dependencies - most people will be expecting to get the same set of 
>>> dependencies as the rest of their team. This pattern makes that harder.
>>> 
>>> NPM shrinkwrap is an example of this, and it’s a bad one - I’ve wasted a 
>>> lot of time trying to keep that up to date for our npm projects. Facebook 
>>> made a replacement for NPM with mainly the  feature of “always locking” in 
>>> yarn  and I’d expect that to take a lot of the JS 
>>> mindshare on this one feature alone.
>>> 
>>> -- 
>>> 
>>> [A.]Orta Therox
>>> 
 w/ Artsy CocoaPods  / CocoaDocs 
  / GIFs.app 
 
 @orta  / orta.github.com 
 Artsy is totally hiring iOS Devs  
 ATM
>>> 
 On 14 Oct 2016, at 07:01, Ankit Aggarwal via swift-build-dev 
 > wrote:
 
 Hi,
 
 We're proposing version pinning feature in Swift Package Manager. The 
 proposal is available here 
 
  and also in this email:
 
 Feedback welcomed!
 
 Thanks,
 Ankit
 
 
 
 Package Manager Version Pinning
 Proposal: SE-
 Author: Daniel Dunbar , Ankit Aggarwal 
 
 Review Manager: TBD
 Status: Discussion
 Introduction
 This is a proposal for adding package manager features to "pin" or "lock" 
 package dependencies to particular versions.
 
 Motivation
 As used in this proposal, version pinning refers to the practice of 
 controlling exactly which specific version of a dependency is selected by 
 the dependency resolution algorithm, independent from the semantic 
 versioning specification. Thus, it is a way of instructing the package 
 manager to select a particular version from among all of the versions of a 
 package which could be chosen while honoring the dependency constraints.
 
 Terminology
 
 We have chosen to use "pinning" to refer to this feature, over 
 "lockfiles", since the term "lock" is already overloaded between POSIX 
 file locks and locks in concurrent programming.
 
 

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

[Daniel Dunbar via swift-evolution]

> 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 seems 
> unreasonable. Updates to code ships bugs. Updates you don’t expect gives you 
> bugs you didn’t expect

Updates you don't expect can also fix bugs you didn't find (or found but hadn't 
diagnosed). I'm not sure it is a one way street.

I completely agree with you here though, you can't trust the tooling. However, 
we also have the ability to test things via running actual tests against 
downstream dependencies. The combination of those two may be quite powerful, 
even if the latter is naturally resource constrained.

> Alexis hits it on the head with the differentiation between a library and an 
> app - libraries should define their own supported ranges, and they require 
> far less locking than applications. An application should always have a lock 
> so you have determinate builds and can update dependencies on purpose.

Yup, we agree here. I'll reply to this on Alexis's post.

> > We generally agree that when you are simply the consumer of packages, 
> > pinning makes sense.
> 
> Isn’t this going to be the majority of the behaviour for the tool on the long 
> run? So I would expect that to be where locking happens.

I don't think so.

Consider the Xcode use case, for example: we are not actively planning on 
adding support for all the myriad kinds of top-level targets and app needs, so 
the packages used in that context will by nature be a package which was shared.

> Sidenote: FWIW not a fan of the name change from lockfile - it feels 
> arbitrary, but I figured the change to a separate command was a bigger 
> elephant in the room.

I agree keeping them in separate threads is handy. I'll reply to this on Max's 
post.

 - Daniel

> 
> -- 
> 
> [A.]  Orta Therox
> 
>> w/ Artsy CocoaPods  / CocoaDocs 
>>  / GIFs.app 
>> 
>> @orta  / orta.github.com 
>> On 14 Oct 2016, at 17:43, Daniel Dunbar > > wrote:
>> 
>> 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 command as it will make builds 
>>> reproducible by default. 
>>> 
>>> I totally agree that we can rely on past experience with other package 
>>> managers (npm being the case), where pinning with a separate command caused 
>>> more harm than good.
>>> 
>>> Overall, I think that it would be great if Package.lock was created by 
>>> default when it's not present and be updated only with an explicit command 
>>> for updating.
>>> 
>>> With best regards, Max.
>>> 
>>> 
 On 14 Oct 2016, at 08:29, orta therox via swift-build-dev 
 > wrote:
 
 Please don’t make this a separate command, it should ideally be created at 
 the end of an build (when there isn’t one already) or an update of your 
 dependencies - most people will be expecting to get the same set of 
 dependencies as the rest of their team. This pattern makes that harder.
 
 NPM shrinkwrap is an example of this, and it’s a bad one - I’ve wasted a 
 lot of time trying to keep that up to date for our npm projects. Facebook 
 made a replacement for NPM with mainly the  feature of “always locking” in 
 yarn  and I’d expect that to take a lot of the JS 
 mindshare on this one feature alone.
 
 -- 
 
 [A.]   Orta Therox
 
> w/ Artsy CocoaPods  / CocoaDocs 
>  / GIFs.app 
> 
> @orta  / orta.github.com 
> 
> Artsy is totally hiring iOS Devs  
> ATM
 
> On 14 Oct 2016, at 07:01, Ankit Aggarwal via swift-build-dev 
> > wrote:
> 
> Hi,
> 
> We're proposing version pinning feature in Swift Package Manager. The 
> proposal is available here 
> 
>  and also in this email:
> 
> Feedback welcomed!
> 
> Thanks,
> Ankit
> 
> 
> 
> Package Manager Version 

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

[Eloy Duran via swift-evolution]

Hey Daniel,

Totally 

I think you should pin by default, I wouldn't even provide some option to 
disable it.

As others have touched on, which I forgot to include, is that a library can 
choose to not include the lock file in SCM. Especially if the lib uses a CI for 
testing, that should bring up any issues with the latest versions of 
dependencies while keeping a paper trail (local lock file) of dependency 
versions that did work.

The key here is that it remains an explicit choice. The default should imo 
always be consistent builds.



With regards to being in a different position, I doubt it. Swift developers 
are, like in other languages, just humans, we all make mistakes. I think we've 
all accepted that we'll always introduce bugs any time we have to make 
decisions, the same applies to determining semantic versions.

You could automate some of that (e.g. check interfaces), but you cannot 
guarantee behavioral intent and thus there's room left for human mistakes.

Please note, though, that I'm kinda pessimistic (realistic) about this and it's 
solely based on experience with established ecosystems, where people generally 
don't like being told how to do things. It may well be that your situation will 
turn out to be different.

As the Queen would say, Godspeed!

> On 14 Oct 2016, at 18:42, Daniel Dunbar  wrote:
> 
> 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 semantic versioning.
>> 
>> While I ideally subscribe to this thought, the truth of the matter is that 
>> this has proven unreliable on multiple occasions. Promoting the idea that it 
>> works is going to inevitably lead users into problems when they did not take 
>> explicit user action to update dependencies.
> 
> This makes a lot of sense to me. The open question in my mind is, given our 
> other goals, are we in a position to make this model work, or to make it "the 
> right model for us". Some of the other things I am considering (and maybe 
> should go into the proposal):
> 
> 1. Swift is still evolving in a much greater way than other languages. That 
> means we continue to need to have a very strong push towards forward 
> versions. This is also true for the package manager features, we need the 
> ecosystem to move forward aggressively so that we can move our own features 
> forward aggressively.
> 
> 2. We have some lofty goals around semantic versioning, like trying to have a 
> much deeper integration with the compiler, API, and ABI, and testing in order 
> to help manage this more effectively.
> 
>> Semantic versioning is a great tool when you decide to sit down and 
>> explicitly update dependencies.
> 
> The problem is they go hand in hand. The more people pin versus following the 
> semantic versioning, the more and more likely it is that those specifications 
> are wrong. That leads to more pinning, which leads to more wrong 
> specifications.
> 
> My preference is that we very aggressively commit to using semantic 
> versioning, and then follow up with the entire cross functional design (an 
> index, if we ever do one, the compiler features, any IDE integration) to make 
> this work. I think we are in a better position than other tools which didn't 
> have the ability to make as many cross functional changes (e.g., integration 
> with the compiler to assist in semantic versioning).
> 
> On the other hand, I am also very pragmatic, and I respect your experience 
> here... if this model simply isn't going to work, then we shouldn't try to go 
> that way.
> 
> The big struggle I have is that if we go the other direction, and as a result 
> people's semantic versions become poorly specified, we will never be able to 
> recover. The converse is not true, if we start with this direction and 
> realize it doesn't work, we can relax our behavior.
> 
>> > We think it will be good for the package ecosystem if such a restriction 
>> > is not the default behavior and that this design will lead to faster 
>> > discovery of bugs and fixes in the upstream.
>> 
>> Again, ideally I would subscribe to this, but the truth is that when people 
>> are working on their projects they *really really really* do *not* like 
>> their builds breaking, especially not when it’s seemingly caused outside of 
>> their own fault.
> 
> One discussion we had a lot was that there are very different workflows 
> between when you are largely the consumer of packages, versus when you are 
> working on a package that is shared.
> 
> We generally agree that when you are simply the consumer of packages, pinning 
> makes sense.
> 
> However, when you are primarily a distributor of packages (and this is 
> expected to *most* of the momentum behind SwiftPM in the near term), 

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

[Huon Wilson via swift-evolution]

> On Oct 14, 2016, at 09:43, Alexis via swift-evolution 
>  wrote:
> 
> A library shouldn’t pin its dependencies, while an application should.

Not only “shouldn’t” but can’t: Rust’s cargo (I don’t know for sure about 
Bundler and Yarn, but they’re all in the same vein, and pretty much from the 
same person) will just ignore any non-top-level lock files, i.e. the package 
that user is working on has a record of the exact versions of everything in 
their dependency graph, and the user can update all or just parts of that graph 
fairly precisely, as desired.

My impression is that other ecosystems without pinning-by-default have 
seriously suffered from the lack of reliable reproducible builds. For instance, 
a major complaint I have seen about "go get” is that one can come back to some 
code after a few months to fix a minor bug and have no chance of getting the 
code to compile, basically just requiring a full rewrite, because dependencies' 
code has changed (or disappeared entirely) and there’s no record of what the 
original was, despite your code being completely untouched in all that time. Of 
course, a hard push towards API-level semantic versioning may allay the worst 
of the code-changing problems, but unless there’s going to be some seriously 
fancy static analysis (something something halting problem), there will be a 
lot of breaking changes that can’t be picked up.

---

To reframe the discussion slightly, not pinning dependencies effectively means 
that the tools are making “random" changes to your code outside your control. 
Sure, those changes were transitively made by possibly-computer-assisted humans 
and may fix bugs, but those pesky meat-bags can still make mistakes, and, they 
don’t see the interactions between all the different packages in your specific 
application.

IME having the predictability of “never changing code under my feet” combined 
with pervasive semantic versioning hits an empowering middle ground of being 
able to depend on many & varied packages and update them to the latest versions 
without fear (for one, it’s easy to revert the lock file if something breaks 
during an update). Feedback from others about cargo is the same, often along 
the lines of “it’s the best package manager I’ve ever used”.

Also, more on the side of implementation details, having a lock file by default 
probably mean one can (get closer to) never hitting the network unless the user 
asks for it, making working offline or on a low-speed/high-latency connection 
easier, i.e. no need to check for new versions of the whole dependency graph on 
O(every) build, which aggressively keeping everything up to date would 
seemingly have to do? (I don’t know swift-pm’s current behavior here, so maybe 
there’s some tricks that avoid it.)

Huon___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Max Desiatov via swift-evolution]

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

I also strongly agree with issues highlighted by Orta, specifically with:

> Updates to code ships bugs. Updates you don’t expect gives you bugs you 
> didn’t expect.

I would prefer the code that compiles on CI to be exactly the same that I run 
locally without having a need to commit all the dependencies. I also think that 
it makes sense for this to be the default behaviour.

With best regards, Max.


> On 14 Oct 2016, at 17:43, Daniel Dunbar  wrote:
> 
> 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 command as it will make builds 
>> reproducible by default. 
>> 
>> I totally agree that we can rely on past experience with other package 
>> managers (npm being the case), where pinning with a separate command caused 
>> more harm than good.
>> 
>> Overall, I think that it would be great if Package.lock was created by 
>> default when it's not present and be updated only with an explicit command 
>> for updating.
>> 
>> With best regards, Max.
>> 
>> 
>>> On 14 Oct 2016, at 08:29, orta therox via swift-build-dev 
>>> > wrote:
>>> 
>>> Please don’t make this a separate command, it should ideally be created at 
>>> the end of an build (when there isn’t one already) or an update of your 
>>> dependencies - most people will be expecting to get the same set of 
>>> dependencies as the rest of their team. This pattern makes that harder.
>>> 
>>> NPM shrinkwrap is an example of this, and it’s a bad one - I’ve wasted a 
>>> lot of time trying to keep that up to date for our npm projects. Facebook 
>>> made a replacement for NPM with mainly the  feature of “always locking” in 
>>> yarn  and I’d expect that to take a lot of the JS 
>>> mindshare on this one feature alone.
>>> 
>>> -- 
>>> 
>>> [A.]Orta Therox
>>> 
 w/ Artsy CocoaPods  / CocoaDocs 
  / GIFs.app 
 
 @orta  / orta.github.com 
 Artsy is totally hiring iOS Devs  
 ATM
>>> 
 On 14 Oct 2016, at 07:01, Ankit Aggarwal via swift-build-dev 
 > wrote:
 
 Hi,
 
 We're proposing version pinning feature in Swift Package Manager. The 
 proposal is available here 
 
  and also in this email:
 
 Feedback welcomed!
 
 Thanks,
 Ankit
 
 
 
 Package Manager Version Pinning
 Proposal: SE-
 Author: Daniel Dunbar , Ankit Aggarwal 
 
 Review Manager: TBD
 Status: Discussion
 Introduction
 This is a proposal for adding package manager features to "pin" or "lock" 
 package dependencies to particular versions.
 
 Motivation
 As used in this proposal, version pinning refers to the practice of 
 controlling exactly which specific version of a dependency is selected by 
 the dependency resolution algorithm, independent from the semantic 
 versioning specification. Thus, it is a way of instructing the package 
 manager to select a particular version from among all of the versions of a 
 package which could be chosen while honoring the dependency constraints.
 
 Terminology
 
 We have chosen to use "pinning" to refer to this feature, over 
 "lockfiles", since the term "lock" is already overloaded between POSIX 
 file locks and locks in concurrent programming.
 
 Philosophy
 
 Our philosophy with regard to pinning is that we actively want to 
 encourage packages to develop against the latest semantically appropriate 
 versions of their dependencies, in order to foster rapid development 
 amongst the ecosystem and strong reliance on the semantic versioning 
 concept. Our design for version pinning is thus intended to be a feature 
 for package authors and users to use in crafting specific workflows, not 
 be a mechanism by which most of the packages in the ecosystem pin 
 themselves to specific versions of each other.
 
 Use Cases
 
 Our proposal is designed to satisfy several different 

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

[Max Desiatov via swift-evolution]

I also strongly agree with this, I'd prefer version pinning to happen by 
default, rather than with explicit command as it will make builds reproducible 
by default. 

I totally agree that we can rely on past experience with other package managers 
(npm being the case), where pinning with a separate command caused more harm 
than good.

Overall, I think that it would be great if Package.lock was created by default 
when it's not present and be updated only with an explicit command for updating.

With best regards, Max.


> On 14 Oct 2016, at 08:29, orta therox via swift-build-dev 
>  wrote:
> 
> Please don’t make this a separate command, it should ideally be created at 
> the end of an build (when there isn’t one already) or an update of your 
> dependencies - most people will be expecting to get the same set of 
> dependencies as the rest of their team. This pattern makes that harder.
> 
> NPM shrinkwrap is an example of this, and it’s a bad one - I’ve wasted a lot 
> of time trying to keep that up to date for our npm projects. Facebook made a 
> replacement for NPM with mainly the  feature of “always locking” in yarn 
>  and I’d expect that to take a lot of the JS mindshare 
> on this one feature alone.
> 
> -- 
> 
> [A.]  Orta Therox
> 
>> w/ Artsy CocoaPods  / CocoaDocs 
>>  / GIFs.app 
>> 
>> @orta  / orta.github.com 
>> Artsy is totally hiring iOS Devs  ATM
> 
>> On 14 Oct 2016, at 07:01, Ankit Aggarwal via swift-build-dev 
>> > wrote:
>> 
>> Hi,
>> 
>> We're proposing version pinning feature in Swift Package Manager. The 
>> proposal is available here 
>> 
>>  and also in this email:
>> 
>> Feedback welcomed!
>> 
>> Thanks,
>> Ankit
>> 
>> 
>> 
>> Package Manager Version Pinning
>> Proposal: SE-
>> Author: Daniel Dunbar , Ankit Aggarwal 
>> 
>> Review Manager: TBD
>> Status: Discussion
>> Introduction
>> This is a proposal for adding package manager features to "pin" or "lock" 
>> package dependencies to particular versions.
>> 
>> Motivation
>> As used in this proposal, version pinning refers to the practice of 
>> controlling exactly which specific version of a dependency is selected by 
>> the dependency resolution algorithm, independent from the semantic 
>> versioning specification. Thus, it is a way of instructing the package 
>> manager to select a particular version from among all of the versions of a 
>> package which could be chosen while honoring the dependency constraints.
>> 
>> Terminology
>> 
>> We have chosen to use "pinning" to refer to this feature, over "lockfiles", 
>> since the term "lock" is already overloaded between POSIX file locks and 
>> locks in concurrent programming.
>> 
>> Philosophy
>> 
>> Our philosophy with regard to pinning is that we actively want to encourage 
>> packages to develop against the latest semantically appropriate versions of 
>> their dependencies, in order to foster rapid development amongst the 
>> ecosystem and strong reliance on the semantic versioning concept. Our design 
>> for version pinning is thus intended to be a feature for package authors and 
>> users to use in crafting specific workflows, not be a mechanism by which 
>> most of the packages in the ecosystem pin themselves to specific versions of 
>> each other.
>> 
>> Use Cases
>> 
>> Our proposal is designed to satisfy several different use cases for such a 
>> behavior:
>> 
>> Standardizing team workflows
>> 
>> When collaborating on a package, it can be valuable for team members (and 
>> continuous integration) to all know they are using the same exact version of 
>> dependencies, to avoid "works for me" situations.
>> 
>> This can be particularly important for certain kinds of open source projects 
>> which are actively being cloned by new users, and which want to have some 
>> measure of control around exactly which available version of a dependency is 
>> selected.
>> 
>> Difficult to test packages or dependencies
>> 
>> Complex packages which have dependencies which may be hard to test, or hard 
>> to analyze when they break, may choose to maintain careful control over what 
>> versions of their upstream dependencies they recommend -- even if 
>> conceptually they regularly update those recommendations following the true 
>> semantic version specification of the dependency.
>> 
>> Dependency locking w.r.t. deployment
>> 
>> When stabilizing a release for deployment, or building a version of a 
>> package for deployment, it is important to be able to lock down the exact 
>> versions of 

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

[Daniel Duan via swift-evolution]

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 point feels out-of-place. Perhaps it deserves its own section.

> On Oct 14, 2016, at 9:26 AM, Daniel Dunbar  wrote:
> 
> 
>> 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 dialect”.
>> 2. SHA/man-in-the-middle attack section needs either more detailed 
>> explanation/reference materials, or shouldn’t be included at all (assuming 
>> when the hash feature gets introduced, there’d be another proposal for it).
> 
> I agree this needs more discussion, but given that we aren't proposing 
> anything here, I feel like it is just a shoutout to an area for future 
> development. What is the harm of having it there?
> 
> One of the possible values of having it in is jumpstarting the actual 
> conversation on the topic!
> 
>  - Daniel
> 
>> 
>> Overall strong +1.
>>> On Oct 13, 2016, at 11:01 PM, Ankit Aggarwal via swift-evolution 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> We're proposing version pinning feature in Swift Package Manager. The 
>>> proposal is available here and also in this email:
>>> 
>>> Feedback welcomed!
>>> 
>>> Thanks,
>>> Ankit
>>> 
>>> 
>>> 
>>> Package Manager Version Pinning
>>> Proposal: SE-
>>> Author: Daniel Dunbar, Ankit Aggarwal
>>> Review Manager: TBD
>>> Status: Discussion
>>> Introduction
>>> This is a proposal for adding package manager features to "pin" or "lock" 
>>> package dependencies to particular versions.
>>> 
>>> Motivation
>>> As used in this proposal, version pinning refers to the practice of 
>>> controlling exactly which specific version of a dependency is selected by 
>>> the dependency resolution algorithm, independent from the semantic 
>>> versioning specification. Thus, it is a way of instructing the package 
>>> manager to select a particular version from among all of the versions of a 
>>> package which could be chosen while honoring the dependency constraints.
>>> 
>>> Terminology
>>> 
>>> We have chosen to use "pinning" to refer to this feature, over "lockfiles", 
>>> since the term "lock" is already overloaded between POSIX file locks and 
>>> locks in concurrent programming.
>>> 
>>> Philosophy
>>> 
>>> Our philosophy with regard to pinning is that we actively want to encourage 
>>> packages to develop against the latest semantically appropriate versions of 
>>> their dependencies, in order to foster rapid development amongst the 
>>> ecosystem and strong reliance on the semantic versioning concept. Our 
>>> design for version pinning is thus intended to be a feature for package 
>>> authors and users to use in crafting specific workflows, not be a mechanism 
>>> by which most of the packages in the ecosystem pin themselves to specific 
>>> versions of each other.
>>> 
>>> Use Cases
>>> 
>>> Our proposal is designed to satisfy several different use cases for such a 
>>> behavior:
>>> 
>>> Standardizing team workflows
>>> 
>>> When collaborating on a package, it can be valuable for team members (and 
>>> continuous integration) to all know they are using the same exact version 
>>> of dependencies, to avoid "works for me" situations.
>>> 
>>> This can be particularly important for certain kinds of open source 
>>> projects which are actively being cloned by new users, and which want to 
>>> have some measure of control around exactly which available version of a 
>>> dependency is selected.
>>> 
>>> Difficult to test packages or dependencies
>>> 
>>> Complex packages which have dependencies which may be hard to test, or hard 
>>> to analyze when they break, may choose to maintain careful control over 
>>> what versions of their upstream dependencies they recommend -- even if 
>>> conceptually they regularly update those recommendations following the true 
>>> semantic version specification of the dependency.
>>> 
>>> Dependency locking w.r.t. deployment
>>> 
>>> When stabilizing a release for deployment, or building a version of a 
>>> package for deployment, it is important to be able to lock down the exact 
>>> versions of dependencies in use, so that the resulting product can be 
>>> exactly recreated later if necessary.
>>> 
>>> Proposed solution
>>> We will introduce support for an optional new file Package.pins adjacent to 
>>> the Package.swift manifest, called the "pins file". We will also introduce 
>>> a number of new commands (see below) for maintaining the pins file.
>>> 
>>> This file will record the active version pin information for the package, 
>>> including data such as the package identifier, the pinned version, and 
>>> explicit 

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

[Daniel Dunbar via swift-evolution]

> 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 point feels out-of-place. Perhaps it deserves its own section.

Good point, let's move it to a future directions section or something.

 - Daniel

> 
> On Oct 14, 2016, at 9:26 AM, Daniel Dunbar  > wrote:
> 
>> 
>>> 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 dialect”.
>>> 2. SHA/man-in-the-middle attack section needs either more detailed 
>>> explanation/reference materials, or shouldn’t be included at all (assuming 
>>> when the hash feature gets introduced, there’d be another proposal for it).
>> 
>> I agree this needs more discussion, but given that we aren't proposing 
>> anything here, I feel like it is just a shoutout to an area for future 
>> development. What is the harm of having it there?
>> 
>> One of the possible values of having it in is jumpstarting the actual 
>> conversation on the topic!
>> 
>>  - Daniel
>> 
>>> 
>>> Overall strong +1.
 On Oct 13, 2016, at 11:01 PM, Ankit Aggarwal via swift-evolution 
 > wrote:
 
 Hi,
 
 We're proposing version pinning feature in Swift Package Manager. The 
 proposal is available here 
 
  and also in this email:
 
 Feedback welcomed!
 
 Thanks,
 Ankit
 
 
 
 Package Manager Version Pinning
 Proposal: SE-
 Author: Daniel Dunbar , Ankit Aggarwal 
 
 Review Manager: TBD
 Status: Discussion
 Introduction
 This is a proposal for adding package manager features to "pin" or "lock" 
 package dependencies to particular versions.
 
 Motivation
 As used in this proposal, version pinning refers to the practice of 
 controlling exactly which specific version of a dependency is selected by 
 the dependency resolution algorithm, independent from the semantic 
 versioning specification. Thus, it is a way of instructing the package 
 manager to select a particular version from among all of the versions of a 
 package which could be chosen while honoring the dependency constraints.
 
 Terminology
 
 We have chosen to use "pinning" to refer to this feature, over 
 "lockfiles", since the term "lock" is already overloaded between POSIX 
 file locks and locks in concurrent programming.
 
 Philosophy
 
 Our philosophy with regard to pinning is that we actively want to 
 encourage packages to develop against the latest semantically appropriate 
 versions of their dependencies, in order to foster rapid development 
 amongst the ecosystem and strong reliance on the semantic versioning 
 concept. Our design for version pinning is thus intended to be a feature 
 for package authors and users to use in crafting specific workflows, not 
 be a mechanism by which most of the packages in the ecosystem pin 
 themselves to specific versions of each other.
 
 Use Cases
 
 Our proposal is designed to satisfy several different use cases for such a 
 behavior:
 
 Standardizing team workflows
 
 When collaborating on a package, it can be valuable for team members (and 
 continuous integration) to all know they are using the same exact version 
 of dependencies, to avoid "works for me" situations.
 
 This can be particularly important for certain kinds of open source 
 projects which are actively being cloned by new users, and which want to 
 have some measure of control around exactly which available version of a 
 dependency is selected.
 
 Difficult to test packages or dependencies
 
 Complex packages which have dependencies which may be hard to test, or 
 hard to analyze when they break, may choose to maintain careful control 
 over what versions of their upstream dependencies they recommend -- even 
 if conceptually they regularly update those recommendations following the 
 true semantic version specification of the dependency.
 
 Dependency locking w.r.t. deployment
 
 When stabilizing a release for deployment, or building a version of a 
 package for deployment, it is important to be able to lock down the 

Re: [swift-evolution] [Discussion] API Guidelines

[Tony Parker via swift-evolution]

Hi Adrian, Charlie,

One additional thing that we considered when naming methods like this was how 
central the operation described in the method was to the overall purpose of the 
type.

For example, the core purpose of an array is to store things. Having functions 
with a base name of ‘add’ or ‘remove’ makes sense. Also, the array(contentsOf:) 
is a special case. Array could store other Arrays (Array), and we 
needed to disambiguate between appending the stuff in the array vs the array 
itself.

We decided that this was not the case for URL (although clearly reasonable 
people could disagree — we made a decision and stuck with it). Therefore: 
appendingPathComponent instead of appending(pathComponent:).

There is no doubt in my mind that these guidelines leave a lot more flexibility 
to the API designer than similar guidelines for Objective-C. That is probably 
best at this point. I think we, as a community, are still evolving the best 
practices. I hope we can learn new patterns and idioms over time as we write 
more and more Swift API. The Objective-C guidelines have evolved dramatically 
from when Objective-C was as young as Swift (think about things like not even 
declaring a method return type and assuming ‘id’, or extending NSObject for 
so-called “informal protocols”, or even the relatively recent addition of 
property syntax).

- Tony

> On Oct 14, 2016, at 7:49 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I’m still not convinced in some cases.
> 
> Take a look at UIViews and its method addSubview.
> 
> open func addSubview(_ view: UIView)
> Personally I’d change or write this function like so:
> 
> open func add(subview: UIView)
> This reduces unnecessary noise _ view for both the implementation and usage.
> 
> // Implementation
> open func add(subview: UIView) {
> // `subview` is descriptive and just fine here
> }
> 
> // Usage
> 
> self.view.add(subview: someOtherView)
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 14. Oktober 2016 um 16:42:06, Zach Waldowski via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> The base name of the function describes its core purpose.
>> 
>> There is no ambiguity instructing an Array to "append" something, but
>> there is context needed: "what are we appending? The contents of the
>> newElements parameter." But there is ambiguity asking URL to "give me a
>> new URL by appending". Appending what? Similarly, telling a collection
>> to "replace". Replace what?
>> 
>> A rule of thumb my team has applied is to put the parameter parens where
>> you would have put `with` in ObjC. This is instructive for your
>> questions as well. "URLByAppendingWithPathComponent" and
>> "replaceWithSubrange" wouldn't make sense, but "appendWithContentsOf"
>> does.
>> 
>> Cheers!
>>   Zachary Waldowski
>>   z...@waldowski.me
>> 
>> On Thu, Oct 13, 2016, at 10:30 PM, Charlie Monroe via swift-evolution
>> wrote:
>> > Hi there,
>> > 
>> > I am really grateful for the API guidelines that were created as part of
>> > Swift 3, however, I'm having trouble with distinguishing which part of
>> > the method name should be already an argument. To illustrate this, here
>> > are two examples:
>> > 
>> > // On Array
>> > public mutating func append(contentsOf newElements: S)
>> > 
>> > // On Foundation.URL
>> > public func appendingPathComponent(_ pathComponent: String) -> URL
>> > 
>> > 
>> > Is there a particular reason why it's not
>> > 
>> > public func appending(pathComponent: String) -> URL
>> > 
>> > ?
>> > 
>> > In my opinion the entire stdlib and Foundation is full of such
>> > discrepancies which make it hard to decide when you name your own methods
>> > since there are preceding cases in the language itself (or Foundation)
>> > that go both ways.
>> > 
>> > The same goes for why don't the replace methods (this is on String)
>> > follow the same - when there is append(contentsOf:):
>> > 
>> > public mutating func replaceSubrange(_ bounds: ClosedRange,
>> > with newElements: String)
>> > 
>> > instead of
>> > 
>> > public mutating func replace(subrange bounds: ClosedRange,
>> > with newElements: String)
>> > 
>> > 
>> > 
>> > I know there was an extensive discussion about this here when the stdlib
>> > names were discussed. And given that these would be breaking changes, I
>> > don't necessarily want to start a lengthy discussion about renaming those
>> > again - I'm just wondering what are the reasons behind this and what
>> > should be the correct naming conventions.
>> > 
>> > Thanks!
>> > 
>> > Charlie
>> > ___
>> > swift-evolution mailing list
>> > swift-evolution@swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> 

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

[Max Desiatov via swift-evolution]

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 JavaScript/Rust/iOS with CocoaPods and then switching to Swift, 
would require a lot of unneeded context switching, as in: "Where's that 
lockfile? I can't find it. Oh great, turns out it's not a lockfile, it's 
something else".

With best regards, Max.

> On 14 Oct 2016, at 17:59, Max Desiatov  wrote:
> 
> I also agree with the point that .lock extension better suits here and 
> adheres to a convention already established in other languages. I personally 
> would prefer the file to be named Package.lock, not Package.pins and also 
> think that it would help newcomers who already used other package managers, 
> especially CocoaPods.
> 
> With best regards, Max.
> 
>> On 14 Oct 2016, at 17:43, 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 feature in Swift Package Manager. The 
>>> proposal is available here 
>>> 
>>>  and also in this email:
>>> 
>>> Feedback welcomed!
>>> 
>>> Thanks,
>>> Ankit
>>> 
>>> 
>>> 
>>> Package Manager Version Pinning
>>> Proposal: SE-
>>> Author: Daniel Dunbar , Ankit Aggarwal 
>>> 
>>> Review Manager: TBD
>>> Status: Discussion
>>> Introduction
>>> This is a proposal for adding package manager features to "pin" or "lock" 
>>> package dependencies to particular versions.
>>> 
>>> Motivation
>>> As used in this proposal, version pinning refers to the practice of 
>>> controlling exactly which specific version of a dependency is selected by 
>>> the dependency resolution algorithm, independent from the semantic 
>>> versioning specification. Thus, it is a way of instructing the package 
>>> manager to select a particular version from among all of the versions of a 
>>> package which could be chosen while honoring the dependency constraints.
>>> 
>>> Terminology
>>> 
>>> We have chosen to use "pinning" to refer to this feature, over "lockfiles", 
>>> since the term "lock" is already overloaded between POSIX file locks and 
>>> locks in concurrent programming.
>>> 
>> I’ve never seen this cause any actual confusion, nor has anyone I know who 
>> teaches/develops these sorts of tools. As far as I can tell, the broader 
>> programming community is rapidly converging on this as standard terminology:
>> 
>> * Gemfile.lock (Ruby)
>> * Cargo.lock (Rust)
>> * Composer.lock (PHP)
>> * yarn.lock (JS)
>> * pubspec.lock (Dart)
>> * Podfile.lock (Swift/Objc!)
>> 
>> Diverging from this seems counter-productive.
>>> Philosophy
>>> 
>>> Our philosophy with regard to pinning is that we actively want to encourage 
>>> packages to develop against the latest semantically appropriate versions of 
>>> their dependencies, in order to foster rapid development amongst the 
>>> ecosystem and strong reliance on the semantic versioning concept. Our 
>>> design for version pinning is thus intended to be a feature for package 
>>> authors and users to use in crafting specific workflows, not be a mechanism 
>>> by which most of the packages in the ecosystem pin themselves to specific 
>>> versions of each other.
>>> 
>>> Use Cases
>>> 
>>> Our proposal is designed to satisfy several different use cases for such a 
>>> behavior:
>>> 
>>> Standardizing team workflows
>>> 
>>> When collaborating on a package, it can be valuable for team members (and 
>>> continuous integration) to all know they are using the same exact version 
>>> of dependencies, to avoid "works for me" situations.
>>> 
>>> This can be particularly important for certain kinds of open source 
>>> projects which are actively being cloned by new users, and which want to 
>>> have some measure of control around exactly which available version of a 
>>> dependency is selected.
>>> 
>>> Difficult to test packages or dependencies
>>> 
>>> Complex packages which have dependencies which may be hard to test, or hard 
>>> to analyze when they break, may choose to maintain careful control over 
>>> what versions of their upstream dependencies they recommend -- even if 
>>> conceptually they regularly update those recommendations following the true 
>>> semantic version specification of the dependency.
>>> 
>>> Dependency locking w.r.t. deployment
>>> 
>>> When stabilizing a release for deployment, or building a version of a 
>>> package for deployment, it is important to be able to lock down the exact 
>>> versions of dependencies in use, so that the resulting product can be 
>>> exactly recreated later if necessary.
>>> 
>>> 

Re: [swift-evolution] Tuples as RawRepresentable

[Karl Wagner via swift-evolution]

Example:


enum something {
case onething
case anotherthing
}
extension something : RawRepresentable {
typealias RawValue = (Int, Int)

init?(rawValue: something.RawValue) {
switch rawValue {
case (1, 1):
self = .onething 
case (2, _):
self = .anotherthing
default:
return  nil 
}
}

var rawValue: (Int, Int) {
switch self {
case .onething: return (1, 1)
case .anotherthing: return (2, 0)
}
}
}

let whatisit = something(rawValue: (1, 1))
something.onething.rawValue

Karl

Sent from my iPad

> On 14 Oct 2016, at 19:04, Karl Wagner  wrote:
> 
> You can already do this; you just need to implement RawRep manually.
> 
> What I think you mean to propose is that the compiler shorthand we have 
> (which synthesises the conformance if you use the equal signs next to the 
> cases) be extended to support tuples of the types it currently supports. 
> That's a relatively simple, non-source-breaking additive change. It likely 
> doesn't fit in the scope of swift 4 phase 1, though (sorry, I've been guilty 
> of chatting about non-abi stuff too as I encounter things which irritate me; 
> trying to be more disciplined)
> 
> Karl
> 
> Sent from my iPad
> 
>> On 14 Oct 2016, at 12:55, Haravikk via swift-evolution 
>>  wrote:
>> 
>> 
>>> On 14 Oct 2016, at 09:49, David Sweeris  wrote:
>>> 
>>> I'm very much in favor of the functionality, but I don't think the 
>>> implementation should rely on compiler magic.
>>> 
>>> - Dave Sweeris 
>> 
>> Well it's not too much in the way of magic really, more just that we need 
>> Swift to see tuples as conforming to RawRepresentable and 
>> ExpressableAsTuple, although they currently aren't types in the normal 
>> sense. So the protocols being used will be the same as you might use 
>> yourself, they'll just be applied automatically for tuples.
>> 
>> It'd be neat if it could be done properly, but that could involve even more 
>> work, but doing this automatically for now should be fairly simple (though I 
>> say that as a person who wouldn't be the one doing it ;)
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rob Allen via swift-evolution]

Hi,

As noted by others, the standard extension for this file .lock, so I would 
prefer to keep that convention.

As I would never want my CI or any random team member to build a different 
package to what I've developed and tested already, I will always want 
Package.lock to exist. It's much easier if the system always creates 
Package.lock on swift package update and always uses it (if it exists) with 
swift build. This way, I get to choose when to go from 1.3.1 to 1.3.2 just in 
case I happen to depend on that bug that's now been fixed…

I can't see any downside to not creating it automatically and it results in so 
much more consistency across a team.

Regards,

Rob...


> On 14 Oct 2016, at 17:29, Daniel Dunbar via swift-build-dev 
>  wrote:
> 
> 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 to, one time, run 
> "package pin --all", and then "git add Package.pins". The latter is always 
> going to be necessary, so are you arguing the first should just be done by 
> default, or is there something deeper here?
> 
>  - Daniel
> 
>> On Oct 14, 2016, at 12:29 AM, orta therox via swift-evolution 
>> > wrote:
>> 
>> Please don’t make this a separate command, it should ideally be created at 
>> the end of an build (when there isn’t one already) or an update of your 
>> dependencies - most people will be expecting to get the same set of 
>> dependencies as the rest of their team. This pattern makes that harder.
>> 
>> NPM shrinkwrap is an example of this, and it’s a bad one - I’ve wasted a lot 
>> of time trying to keep that up to date for our npm projects. Facebook made a 
>> replacement for NPM with mainly the  feature of “always locking” in yarn 
>>  and I’d expect that to take a lot of the JS mindshare 
>> on this one feature alone.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Daniel Dunbar via swift-evolution]

> 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 dialect”.
> 2. SHA/man-in-the-middle attack section needs either more detailed 
> explanation/reference materials, or shouldn’t be included at all (assuming 
> when the hash feature gets introduced, there’d be another proposal for it).

I agree this needs more discussion, but given that we aren't proposing anything 
here, I feel like it is just a shoutout to an area for future development. What 
is the harm of having it there?

One of the possible values of having it in is jumpstarting the actual 
conversation on the topic!

 - Daniel

> 
> Overall strong +1.
>> On Oct 13, 2016, at 11:01 PM, Ankit Aggarwal via swift-evolution 
>> > wrote:
>> 
>> Hi,
>> 
>> We're proposing version pinning feature in Swift Package Manager. The 
>> proposal is available here 
>> 
>>  and also in this email:
>> 
>> Feedback welcomed!
>> 
>> Thanks,
>> Ankit
>> 
>> 
>> 
>> Package Manager Version Pinning
>> Proposal: SE-
>> Author: Daniel Dunbar , Ankit Aggarwal 
>> 
>> Review Manager: TBD
>> Status: Discussion
>> Introduction
>> This is a proposal for adding package manager features to "pin" or "lock" 
>> package dependencies to particular versions.
>> 
>> Motivation
>> As used in this proposal, version pinning refers to the practice of 
>> controlling exactly which specific version of a dependency is selected by 
>> the dependency resolution algorithm, independent from the semantic 
>> versioning specification. Thus, it is a way of instructing the package 
>> manager to select a particular version from among all of the versions of a 
>> package which could be chosen while honoring the dependency constraints.
>> 
>> Terminology
>> 
>> We have chosen to use "pinning" to refer to this feature, over "lockfiles", 
>> since the term "lock" is already overloaded between POSIX file locks and 
>> locks in concurrent programming.
>> 
>> Philosophy
>> 
>> Our philosophy with regard to pinning is that we actively want to encourage 
>> packages to develop against the latest semantically appropriate versions of 
>> their dependencies, in order to foster rapid development amongst the 
>> ecosystem and strong reliance on the semantic versioning concept. Our design 
>> for version pinning is thus intended to be a feature for package authors and 
>> users to use in crafting specific workflows, not be a mechanism by which 
>> most of the packages in the ecosystem pin themselves to specific versions of 
>> each other.
>> 
>> Use Cases
>> 
>> Our proposal is designed to satisfy several different use cases for such a 
>> behavior:
>> 
>> Standardizing team workflows
>> 
>> When collaborating on a package, it can be valuable for team members (and 
>> continuous integration) to all know they are using the same exact version of 
>> dependencies, to avoid "works for me" situations.
>> 
>> This can be particularly important for certain kinds of open source projects 
>> which are actively being cloned by new users, and which want to have some 
>> measure of control around exactly which available version of a dependency is 
>> selected.
>> 
>> Difficult to test packages or dependencies
>> 
>> Complex packages which have dependencies which may be hard to test, or hard 
>> to analyze when they break, may choose to maintain careful control over what 
>> versions of their upstream dependencies they recommend -- even if 
>> conceptually they regularly update those recommendations following the true 
>> semantic version specification of the dependency.
>> 
>> Dependency locking w.r.t. deployment
>> 
>> When stabilizing a release for deployment, or building a version of a 
>> package for deployment, it is important to be able to lock down the exact 
>> versions of dependencies in use, so that the resulting product can be 
>> exactly recreated later if necessary.
>> 
>> Proposed solution
>> We will introduce support for an optional new file Package.pins adjacent to 
>> the Package.swift manifest, called the "pins file". We will also introduce a 
>> number of new commands (see below) for maintaining the pins file.
>> 
>> This file will record the active version pin information for the package, 
>> including data such as the package identifier, the pinned version, and 
>> explicit information on the pinned version (e.g., the commit hash/SHA for 
>> the resolved tag).
>> 
>> The exact file format is unspecified/implementation defined, however, in 
>> practice it will be a JSON data file.
>> 
>> This file may be checked into SCM by the user, so that 

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

[Daniel Dunbar via swift-evolution]

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 to, one time, run "package pin 
--all", and then "git add Package.pins". The latter is always going to be 
necessary, so are you arguing the first should just be done by default, or is 
there something deeper here?

 - Daniel

> On Oct 14, 2016, at 12:29 AM, orta therox via swift-evolution 
>  wrote:
> 
> Please don’t make this a separate command, it should ideally be created at 
> the end of an build (when there isn’t one already) or an update of your 
> dependencies - most people will be expecting to get the same set of 
> dependencies as the rest of their team. This pattern makes that harder.
> 
> NPM shrinkwrap is an example of this, and it’s a bad one - I’ve wasted a lot 
> of time trying to keep that up to date for our npm projects. Facebook made a 
> replacement for NPM with mainly the  feature of “always locking” in yarn 
>  and I’d expect that to take a lot of the JS mindshare 
> on this one feature alone.
> 
> -- 
> 
> [A.]  Orta Therox
> 
>> w/ Artsy CocoaPods  / CocoaDocs 
>>  / GIFs.app 
>> 
>> @orta  / orta.github.com 
>> Artsy is totally hiring iOS Devs  ATM
> 
>> On 14 Oct 2016, at 07:01, Ankit Aggarwal via swift-build-dev 
>> > wrote:
>> 
>> Hi,
>> 
>> We're proposing version pinning feature in Swift Package Manager. The 
>> proposal is available here 
>> 
>>  and also in this email:
>> 
>> Feedback welcomed!
>> 
>> Thanks,
>> Ankit
>> 
>> 
>> 
>> Package Manager Version Pinning
>> Proposal: SE-
>> Author: Daniel Dunbar , Ankit Aggarwal 
>> 
>> Review Manager: TBD
>> Status: Discussion
>> Introduction
>> This is a proposal for adding package manager features to "pin" or "lock" 
>> package dependencies to particular versions.
>> 
>> Motivation
>> As used in this proposal, version pinning refers to the practice of 
>> controlling exactly which specific version of a dependency is selected by 
>> the dependency resolution algorithm, independent from the semantic 
>> versioning specification. Thus, it is a way of instructing the package 
>> manager to select a particular version from among all of the versions of a 
>> package which could be chosen while honoring the dependency constraints.
>> 
>> Terminology
>> 
>> We have chosen to use "pinning" to refer to this feature, over "lockfiles", 
>> since the term "lock" is already overloaded between POSIX file locks and 
>> locks in concurrent programming.
>> 
>> Philosophy
>> 
>> Our philosophy with regard to pinning is that we actively want to encourage 
>> packages to develop against the latest semantically appropriate versions of 
>> their dependencies, in order to foster rapid development amongst the 
>> ecosystem and strong reliance on the semantic versioning concept. Our design 
>> for version pinning is thus intended to be a feature for package authors and 
>> users to use in crafting specific workflows, not be a mechanism by which 
>> most of the packages in the ecosystem pin themselves to specific versions of 
>> each other.
>> 
>> Use Cases
>> 
>> Our proposal is designed to satisfy several different use cases for such a 
>> behavior:
>> 
>> Standardizing team workflows
>> 
>> When collaborating on a package, it can be valuable for team members (and 
>> continuous integration) to all know they are using the same exact version of 
>> dependencies, to avoid "works for me" situations.
>> 
>> This can be particularly important for certain kinds of open source projects 
>> which are actively being cloned by new users, and which want to have some 
>> measure of control around exactly which available version of a dependency is 
>> selected.
>> 
>> Difficult to test packages or dependencies
>> 
>> Complex packages which have dependencies which may be hard to test, or hard 
>> to analyze when they break, may choose to maintain careful control over what 
>> versions of their upstream dependencies they recommend -- even if 
>> conceptually they regularly update those recommendations following the true 
>> semantic version specification of the dependency.
>> 
>> Dependency locking w.r.t. deployment
>> 
>> When stabilizing a release for deployment, or building a version of a 
>> package for deployment, it is important to be able to lock down the exact 
>> versions of 

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

[Daniel Dunbar via swift-evolution]

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 semantic versioning.
> 
> While I ideally subscribe to this thought, the truth of the matter is that 
> this has proven unreliable on multiple occasions. Promoting the idea that it 
> works is going to inevitably lead users into problems when they did not take 
> explicit user action to update dependencies.

This makes a lot of sense to me. The open question in my mind is, given our 
other goals, are we in a position to make this model work, or to make it "the 
right model for us". Some of the other things I am considering (and maybe 
should go into the proposal):

1. Swift is still evolving in a much greater way than other languages. That 
means we continue to need to have a very strong push towards forward versions. 
This is also true for the package manager features, we need the ecosystem to 
move forward aggressively so that we can move our own features forward 
aggressively.

2. We have some lofty goals around semantic versioning, like trying to have a 
much deeper integration with the compiler, API, and ABI, and testing in order 
to help manage this more effectively.

> Semantic versioning is a great tool when you decide to sit down and 
> explicitly update dependencies.

The problem is they go hand in hand. The more people pin versus following the 
semantic versioning, the more and more likely it is that those specifications 
are wrong. That leads to more pinning, which leads to more wrong specifications.

My preference is that we very aggressively commit to using semantic versioning, 
and then follow up with the entire cross functional design (an index, if we 
ever do one, the compiler features, any IDE integration) to make this work. I 
think we are in a better position than other tools which didn't have the 
ability to make as many cross functional changes (e.g., integration with the 
compiler to assist in semantic versioning).

On the other hand, I am also very pragmatic, and I respect your experience 
here... if this model simply isn't going to work, then we shouldn't try to go 
that way.

The big struggle I have is that if we go the other direction, and as a result 
people's semantic versions become poorly specified, we will never be able to 
recover. The converse is not true, if we start with this direction and realize 
it doesn't work, we can relax our behavior.

> > We think it will be good for the package ecosystem if such a restriction is 
> > not the default behavior and that this design will lead to faster discovery 
> > of bugs and fixes in the upstream.
> 
> Again, ideally I would subscribe to this, but the truth is that when people 
> are working on their projects they *really really really* do *not* like their 
> builds breaking, especially not when it’s seemingly caused outside of their 
> own fault.

One discussion we had a lot was that there are very different workflows between 
when you are largely the consumer of packages, versus when you are working on a 
package that is shared.

We generally agree that when you are simply the consumer of packages, pinning 
makes sense.

However, when you are primarily a distributor of packages (and this is expected 
to *most* of the momentum behind SwiftPM in the near term), I believe that it 
is very important to the ecosystem that the semver specs be correct, and so 
even if the team *wants* to pin, doing so would be actively harmful.

> In the end, it comes down to whether you prioritise surfacing bugs (long term 
> happiness) over user-experience (short term happiness). As a dependency 
> manager author, I can tell you that I agree with your ideals and would want 
> to choose the former, but as a user of dependency managers I would choose UX 
> and Getting (The) Things (I Really Wanted To Do) Done over surfacing bugs 
> *any* day.

I really appreciate the feedback. Do my arguments that we might be in a 
position to do better here have any weight with you?

 - Daniel

> 
> [A.]  Eloy Durán
>   Artsy 
>   
>   e...@artsy.net   Twitter 
> 
>   GitHub 
>> On 14 Oct 2016, at 09:29, orta therox via swift-build-dev 
>> > wrote:
>> 
>> Please don’t make this a separate command, it should ideally be created at 
>> the end of an build (when there isn’t one already) or an update of your 
>> dependencies - most people will be expecting to get the same set of 
>> dependencies as the rest of their team. This pattern makes that harder.
>> 
>> NPM shrinkwrap is an example of this, and it’s a bad one - I’ve wasted a lot 
>> of time trying to 

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

[Alexis via swift-evolution]

> On Oct 14, 2016, at 2:01 AM, Ankit Aggarwal via swift-evolution 
>  wrote:
> 
> Hi,
> 
> We're proposing version pinning feature in Swift Package Manager. The 
> proposal is available here 
> 
>  and also in this email:
> 
> Feedback welcomed!
> 
> Thanks,
> Ankit
> 
> 
> 
> Package Manager Version Pinning
> Proposal: SE-
> Author: Daniel Dunbar , Ankit Aggarwal 
> 
> Review Manager: TBD
> Status: Discussion
> Introduction
> This is a proposal for adding package manager features to "pin" or "lock" 
> package dependencies to particular versions.
> 
> Motivation
> As used in this proposal, version pinning refers to the practice of 
> controlling exactly which specific version of a dependency is selected by the 
> dependency resolution algorithm, independent from the semantic versioning 
> specification. Thus, it is a way of instructing the package manager to select 
> a particular version from among all of the versions of a package which could 
> be chosen while honoring the dependency constraints.
> 
> Terminology
> 
> We have chosen to use "pinning" to refer to this feature, over "lockfiles", 
> since the term "lock" is already overloaded between POSIX file locks and 
> locks in concurrent programming.
> 
I’ve never seen this cause any actual confusion, nor has anyone I know who 
teaches/develops these sorts of tools. As far as I can tell, the broader 
programming community is rapidly converging on this as standard terminology:

* Gemfile.lock (Ruby)
* Cargo.lock (Rust)
* Composer.lock (PHP)
* yarn.lock (JS)
* pubspec.lock (Dart)
* Podfile.lock (Swift/Objc!)

Diverging from this seems counter-productive.
> Philosophy
> 
> Our philosophy with regard to pinning is that we actively want to encourage 
> packages to develop against the latest semantically appropriate versions of 
> their dependencies, in order to foster rapid development amongst the 
> ecosystem and strong reliance on the semantic versioning concept. Our design 
> for version pinning is thus intended to be a feature for package authors and 
> users to use in crafting specific workflows, not be a mechanism by which most 
> of the packages in the ecosystem pin themselves to specific versions of each 
> other.
> 
> Use Cases
> 
> Our proposal is designed to satisfy several different use cases for such a 
> behavior:
> 
> Standardizing team workflows
> 
> When collaborating on a package, it can be valuable for team members (and 
> continuous integration) to all know they are using the same exact version of 
> dependencies, to avoid "works for me" situations.
> 
> This can be particularly important for certain kinds of open source projects 
> which are actively being cloned by new users, and which want to have some 
> measure of control around exactly which available version of a dependency is 
> selected.
> 
> Difficult to test packages or dependencies
> 
> Complex packages which have dependencies which may be hard to test, or hard 
> to analyze when they break, may choose to maintain careful control over what 
> versions of their upstream dependencies they recommend -- even if 
> conceptually they regularly update those recommendations following the true 
> semantic version specification of the dependency.
> 
> Dependency locking w.r.t. deployment
> 
> When stabilizing a release for deployment, or building a version of a package 
> for deployment, it is important to be able to lock down the exact versions of 
> dependencies in use, so that the resulting product can be exactly recreated 
> later if necessary.
> 
> Proposed solution
> We will introduce support for an optional new file Package.pins adjacent to 
> the Package.swift manifest, called the "pins file". We will also introduce a 
> number of new commands (see below) for maintaining the pins file.
> 
> This file will record the active version pin information for the package, 
> including data such as the package identifier, the pinned version, and 
> explicit information on the pinned version (e.g., the commit hash/SHA for the 
> resolved tag).
> 
> The exact file format is unspecified/implementation defined, however, in 
> practice it will be a JSON data file.
> 
> This file may be checked into SCM by the user, so that its effects apply to 
> all users of the package. However, it may also be maintained only locally 
> (e.g., placed in the .gitignore file). We intend to leave it to package 
> authors to decide which use case is best for their project.
> 
> In the presence of a Package.pins file, the package manager will respect the 
> pinned dependencies recorded in the file whenever it needs to do dependency 
> resolution (e.g., on the initial checkout or when updating).
> 
> The pins file will not override Manifest specified version requirements and 
> it will be an error (with proper 

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

[Daniel Dunbar via swift-evolution]

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 command as it will make builds 
> reproducible by default. 
> 
> I totally agree that we can rely on past experience with other package 
> managers (npm being the case), where pinning with a separate command caused 
> more harm than good.
> 
> Overall, I think that it would be great if Package.lock was created by 
> default when it's not present and be updated only with an explicit command 
> for updating.
> 
> With best regards, Max.
> 
> 
>> On 14 Oct 2016, at 08:29, orta therox via swift-build-dev 
>> > wrote:
>> 
>> Please don’t make this a separate command, it should ideally be created at 
>> the end of an build (when there isn’t one already) or an update of your 
>> dependencies - most people will be expecting to get the same set of 
>> dependencies as the rest of their team. This pattern makes that harder.
>> 
>> NPM shrinkwrap is an example of this, and it’s a bad one - I’ve wasted a lot 
>> of time trying to keep that up to date for our npm projects. Facebook made a 
>> replacement for NPM with mainly the  feature of “always locking” in yarn 
>>  and I’d expect that to take a lot of the JS mindshare 
>> on this one feature alone.
>> 
>> -- 
>> 
>> [A.] Orta Therox
>> 
>>> w/ Artsy CocoaPods  / CocoaDocs 
>>>  / GIFs.app 
>>> 
>>> @orta  / orta.github.com 
>>> Artsy is totally hiring iOS Devs  ATM
>> 
>>> On 14 Oct 2016, at 07:01, Ankit Aggarwal via swift-build-dev 
>>> > wrote:
>>> 
>>> Hi,
>>> 
>>> We're proposing version pinning feature in Swift Package Manager. The 
>>> proposal is available here 
>>> 
>>>  and also in this email:
>>> 
>>> Feedback welcomed!
>>> 
>>> Thanks,
>>> Ankit
>>> 
>>> 
>>> 
>>> Package Manager Version Pinning
>>> Proposal: SE-
>>> Author: Daniel Dunbar , Ankit Aggarwal 
>>> 
>>> Review Manager: TBD
>>> Status: Discussion
>>> Introduction
>>> This is a proposal for adding package manager features to "pin" or "lock" 
>>> package dependencies to particular versions.
>>> 
>>> Motivation
>>> As used in this proposal, version pinning refers to the practice of 
>>> controlling exactly which specific version of a dependency is selected by 
>>> the dependency resolution algorithm, independent from the semantic 
>>> versioning specification. Thus, it is a way of instructing the package 
>>> manager to select a particular version from among all of the versions of a 
>>> package which could be chosen while honoring the dependency constraints.
>>> 
>>> Terminology
>>> 
>>> We have chosen to use "pinning" to refer to this feature, over "lockfiles", 
>>> since the term "lock" is already overloaded between POSIX file locks and 
>>> locks in concurrent programming.
>>> 
>>> Philosophy
>>> 
>>> Our philosophy with regard to pinning is that we actively want to encourage 
>>> packages to develop against the latest semantically appropriate versions of 
>>> their dependencies, in order to foster rapid development amongst the 
>>> ecosystem and strong reliance on the semantic versioning concept. Our 
>>> design for version pinning is thus intended to be a feature for package 
>>> authors and users to use in crafting specific workflows, not be a mechanism 
>>> by which most of the packages in the ecosystem pin themselves to specific 
>>> versions of each other.
>>> 
>>> Use Cases
>>> 
>>> Our proposal is designed to satisfy several different use cases for such a 
>>> behavior:
>>> 
>>> Standardizing team workflows
>>> 
>>> When collaborating on a package, it can be valuable for team members (and 
>>> continuous integration) to all know they are using the same exact version 
>>> of dependencies, to avoid "works for me" situations.
>>> 
>>> This can be particularly important for certain kinds of open source 
>>> projects which are actively being cloned by new users, and which want to 
>>> have some measure of control around exactly which available version of a 
>>> dependency is selected.
>>> 
>>> Difficult to test packages or dependencies
>>> 
>>> Complex packages which have dependencies which may be hard to test, or hard 
>>> to analyze when they break, may choose to maintain careful control over 
>>> what versions of their upstream dependencies they recommend -- even if 
>>> 

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

[Max Desiatov via swift-evolution]

I also agree with the point that .lock extension better suits here and adheres 
to a convention already established in other languages. I personally would 
prefer the file to be named Package.lock, not Package.pins and also think that 
it would help newcomers who already used other package managers, especially 
CocoaPods.

With best regards, Max.

> On 14 Oct 2016, at 17:43, 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 feature in Swift Package Manager. The 
>> proposal is available here 
>> 
>>  and also in this email:
>> 
>> Feedback welcomed!
>> 
>> Thanks,
>> Ankit
>> 
>> 
>> 
>> Package Manager Version Pinning
>> Proposal: SE-
>> Author: Daniel Dunbar , Ankit Aggarwal 
>> 
>> Review Manager: TBD
>> Status: Discussion
>> Introduction
>> This is a proposal for adding package manager features to "pin" or "lock" 
>> package dependencies to particular versions.
>> 
>> Motivation
>> As used in this proposal, version pinning refers to the practice of 
>> controlling exactly which specific version of a dependency is selected by 
>> the dependency resolution algorithm, independent from the semantic 
>> versioning specification. Thus, it is a way of instructing the package 
>> manager to select a particular version from among all of the versions of a 
>> package which could be chosen while honoring the dependency constraints.
>> 
>> Terminology
>> 
>> We have chosen to use "pinning" to refer to this feature, over "lockfiles", 
>> since the term "lock" is already overloaded between POSIX file locks and 
>> locks in concurrent programming.
>> 
> I’ve never seen this cause any actual confusion, nor has anyone I know who 
> teaches/develops these sorts of tools. As far as I can tell, the broader 
> programming community is rapidly converging on this as standard terminology:
> 
> * Gemfile.lock (Ruby)
> * Cargo.lock (Rust)
> * Composer.lock (PHP)
> * yarn.lock (JS)
> * pubspec.lock (Dart)
> * Podfile.lock (Swift/Objc!)
> 
> Diverging from this seems counter-productive.
>> Philosophy
>> 
>> Our philosophy with regard to pinning is that we actively want to encourage 
>> packages to develop against the latest semantically appropriate versions of 
>> their dependencies, in order to foster rapid development amongst the 
>> ecosystem and strong reliance on the semantic versioning concept. Our design 
>> for version pinning is thus intended to be a feature for package authors and 
>> users to use in crafting specific workflows, not be a mechanism by which 
>> most of the packages in the ecosystem pin themselves to specific versions of 
>> each other.
>> 
>> Use Cases
>> 
>> Our proposal is designed to satisfy several different use cases for such a 
>> behavior:
>> 
>> Standardizing team workflows
>> 
>> When collaborating on a package, it can be valuable for team members (and 
>> continuous integration) to all know they are using the same exact version of 
>> dependencies, to avoid "works for me" situations.
>> 
>> This can be particularly important for certain kinds of open source projects 
>> which are actively being cloned by new users, and which want to have some 
>> measure of control around exactly which available version of a dependency is 
>> selected.
>> 
>> Difficult to test packages or dependencies
>> 
>> Complex packages which have dependencies which may be hard to test, or hard 
>> to analyze when they break, may choose to maintain careful control over what 
>> versions of their upstream dependencies they recommend -- even if 
>> conceptually they regularly update those recommendations following the true 
>> semantic version specification of the dependency.
>> 
>> Dependency locking w.r.t. deployment
>> 
>> When stabilizing a release for deployment, or building a version of a 
>> package for deployment, it is important to be able to lock down the exact 
>> versions of dependencies in use, so that the resulting product can be 
>> exactly recreated later if necessary.
>> 
>> Proposed solution
>> We will introduce support for an optional new file Package.pins adjacent to 
>> the Package.swift manifest, called the "pins file". We will also introduce a 
>> number of new commands (see below) for maintaining the pins file.
>> 
>> This file will record the active version pin information for the package, 
>> including data such as the package identifier, the pinned version, and 
>> explicit information on the pinned version (e.g., the commit hash/SHA for 
>> the resolved tag).
>> 
>> The exact file format is unspecified/implementation defined, however, in 
>> practice it will be a JSON data file.
>> 
>> This file may be checked 

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

[Daniel Dunbar via swift-evolution]

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
>  
> 
> 
> Daniel Duan
> Sent from my iPhone
> 
> On Oct 14, 2016, at 7:14 AM, Goffredo Marocchi  > wrote:
> 
>> Let's not promote this idea English has comprehensible and easy to refer to 
>> pronunciation rules ;). It needs reforming :P, but let's keep it for 
>> English-Evolution ;).
>> 
>> Sent from my iPhone
>> 
>>> On 14 Oct 2016, at 13:42, Haravikk via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On 14 Oct 2016, at 07:16, Daniel Duan via swift-evolution 
 > wrote:
 
 1. “honor” is mis-spelled in “weird queen’s dialect”.
>>> 
>>> I'm sorry, but I throw an exception at this; when you say "weird queen's 
>>> dialect" do you mean… English? I don't go around referring to the other 
>>> variation as "weird can't spell dialect" (but maybe I should) 
>>> The u in words like honour is what makes it pronounced like "onner" rather 
>>> than "hone-ore", same with colour being "culler" rather than "coal-ore". 
>>> Sorry but it really annoys me when people consider the English version of 
>>> English to be the weird one, as the clue is literally in the name as to 
>>> which version is correct. This is why it still galls me that the language 
>>> in macOS is "British English" yet the other one is just "English" rather 
>>> than "American English" or whatever, it's a hideous double standard.
>>> 
>>> 
>>> That aside, I'm a strong +1 for the feature 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Tuples as RawRepresentable

[Karl Wagner via swift-evolution]

You can already do this; you just need to implement RawRep manually.

What I think you mean to propose is that the compiler shorthand we have (which 
synthesises the conformance if you use the equal signs next to the cases) be 
extended to support tuples of the types it currently supports. That's a 
relatively simple, non-source-breaking additive change. It likely doesn't fit 
in the scope of swift 4 phase 1, though (sorry, I've been guilty of chatting 
about non-abi stuff too as I encounter things which irritate me; trying to be 
more disciplined)

Karl

Sent from my iPad

> On 14 Oct 2016, at 12:55, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 14 Oct 2016, at 09:49, David Sweeris  wrote:
>> 
>> I'm very much in favor of the functionality, but I don't think the 
>> implementation should rely on compiler magic.
>> 
>> - Dave Sweeris 
> 
> Well it's not too much in the way of magic really, more just that we need 
> Swift to see tuples as conforming to RawRepresentable and ExpressableAsTuple, 
> although they currently aren't types in the normal sense. So the protocols 
> being used will be the same as you might use yourself, they'll just be 
> applied automatically for tuples.
> 
> It'd be neat if it could be done properly, but that could involve even more 
> work, but doing this automatically for now should be fairly simple (though I 
> say that as a person who wouldn't be the one doing it ;)
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ryan Lovelett via swift-evolution]

> 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 the
> connotation actually works fairly well (e.g., a pinboard is something
> you pin to while working, or pinning a dress while you stitch it). I
> also wasn't a huge fan of pin initially, but as it bounced around in
> my head for a while I really started to like it, for exactly this
> connotation reason.

I think this comment drives at the core of the difference between this
proposal and what Orta, Alexis and others are saying. (At least for me)

The description you've provided here, specifically the word "workflow",
and the concept of operations described by the proprosal are meant to be
a transient. They are meant as a temporary description of how these
dependencies should be kept in order.  To my mind one "puts a pin" in
something temporarily. To comeback to it later to do something with it
at that time. Thus the pin probably does work with this concept.

Conversely, the concept of "locking" something feels less transient. It
feels more permanent. More like the concept of operations described by
Orta, Alexis and others. Idle speculation: might be why those other
managers selected the word lock.

Not sure where I come down on the whole thing yet. Just wanted to say
that if the propsal goes another way than what was first propsed  a new
word likely should be investigated.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Out of scope][Gibberish]

[Ted F.A. van Gaalen via swift-evolution]

Trivial matter, I’d say. How lucky you are:
Just be glad you’re not  Dutch living in Germany (the lady is from here), 
writing on English boards. :o)

https://www.youtube.com/watch?v=WcEFn-1uOyo 


Have a nice weekend, met vriendelijke groeten
TedvG

> On 14 Oct 2016, at 07:16, Daniel Duan via swift-evolution 
> > wrote:
> 
> 1. “honor” is mis-spelled in “weird queen’s dialect”.

I'm sorry, but I throw an exception at this; when you say "weird queen's 
dialect" do you mean… English? I don't go around referring to the other 
variation as "weird can't spell dialect" (but maybe I should) 
The u in words like honour is what makes it pronounced like "onner" rather than 
"hone-ore", same with colour being "culler" rather than "coal-ore". Sorry but 
it really annoys me when people consider the English version of English to be 
the weird one, as the clue is literally in the name as to which version is 
correct. This is why it still galls me that the language in macOS is "British 
English" yet the other one is just "English" rather than "American English" or 
whatever, it's a hideous double standard.


That aside, I'm a strong +1 for the feature 

--

Message: 2
Date: Fri, 14 Oct 2016 16:14:01 +0200
From: Goffredo Marocchi >
To: Haravikk >
Cc: swift-evolution@swift.org , 
swift-build-...@swift.org 
Subject: Re: [swift-evolution] Proposal: Package Manager Version
Pinning
Message-ID: <5c0dd558-5031-4d9c-9444-106b2dd37...@gmail.com 
>
Content-Type: text/plain;   charset=utf-8

Let's not promote this idea English has comprehensible and easy to refer to 
pronunciation rules ;). It needs reforming :P, but let's keep it for 
English-Evolution ;).

Sent from my iPhone

> On 14 Oct 2016, at 13:42, Haravikk via swift-evolution 
> > wrote:
> 
> 
>> On 14 Oct 2016, at 07:16, Daniel Duan via swift-evolution 
>> > wrote:
>> 
>> 1. “honor” is mis-spelled in “weird queen’s dialect”.
> 
> I'm sorry, but I throw an exception at this; when you say "weird queen's 
> dialect" do you mean… English? I don't go around referring to the other 
> variation as "weird can't spell dialect" (but maybe I should) 
> The u in words like honour is what makes it pronounced like "onner" rather 
> than "hone-ore", same with colour being "culler" rather than "coal-ore". 
> Sorry but it really annoys me when people consider the English version of 
> English to be the weird one, as the clue is literally in the name as to which 
> version is correct. This is why it still galls me that the language in macOS 
> is "British English" yet the other one is just "English" rather than 
> "American English" or whatever, it's a hideous double standard.
> 
> 
> That aside, I'm a strong +1 for the feature 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 


--

Message: 3
Date: Fri, 14 Oct 2016 09:34:10 -0500
From: Benjamin Spratling >
To: swift-evolution@swift.org 
Subject: Re: [swift-evolution] Proposal: Package Manager Version
Pinning
Message-ID: <9ef2369d-4182-4630-ba92-e037c4082...@mac.com 
>
Content-Type: text/plain; charset=us-ascii

> Let's not promote this idea English has comprehensible and easy to refer to 
> pronunciation rules ;). It needs reforming :P, but let's keep it for 
> English-Evolution ;).


+1
 Can you get me on that list?  I have a long list of bugs to report. :)

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Tuples as RawRepresentable

[Haravikk via swift-evolution]

Huh, see, that's why I posted the thread; I didn't know you could do it that 
way (I've been trying the RawRepresentable part as its own type).
In that case yes, it seems like all that's need is an expansion of what's 
allowable on the rhs of raw value enum cases.

> On 14 Oct 2016, at 18:11, Karl Wagner  wrote:
> 
> Example:
> 
> 
> enum something {
> case onething
> case anotherthing
> }
> extension something : RawRepresentable {
> typealias RawValue = (Int, Int)
> 
> init?(rawValue: something.RawValue) {
> switch rawValue {
> case (1, 1):
> self = .onething 
> case (2, _):
> self = .anotherthing
> default:
> return  nil 
> }
> }
> 
> var rawValue: (Int, Int) {
> switch self {
> case .onething: return (1, 1)
> case .anotherthing: return (2, 0)
> }
> }
> }
> 
> let whatisit = something(rawValue: (1, 1))
> something.onething.rawValue
> 
> Karl
> 
> Sent from my iPad
> 
> On 14 Oct 2016, at 19:04, Karl Wagner  > wrote:
> 
>> You can already do this; you just need to implement RawRep manually.
>> 
>> What I think you mean to propose is that the compiler shorthand we have 
>> (which synthesises the conformance if you use the equal signs next to the 
>> cases) be extended to support tuples of the types it currently supports. 
>> That's a relatively simple, non-source-breaking additive change. It likely 
>> doesn't fit in the scope of swift 4 phase 1, though (sorry, I've been guilty 
>> of chatting about non-abi stuff too as I encounter things which irritate me; 
>> trying to be more disciplined)
>> 
>> Karl
>> 
>> Sent from my iPad
>> 
>> On 14 Oct 2016, at 12:55, Haravikk via swift-evolution 
>> > wrote:
>> 
>>> 
 On 14 Oct 2016, at 09:49, David Sweeris > wrote:
 
 I'm very much in favor of the functionality, but I don't think the 
 implementation should rely on compiler magic.
 
 - Dave Sweeris 
>>> 
>>> Well it's not too much in the way of magic really, more just that we need 
>>> Swift to see tuples as conforming to RawRepresentable and 
>>> ExpressableAsTuple, although they currently aren't types in the normal 
>>> sense. So the protocols being used will be the same as you might use 
>>> yourself, they'll just be applied automatically for tuples.
>>> 
>>> It'd be neat if it could be done properly, but that could involve even more 
>>> work, but doing this automatically for now should be fairly simple (though 
>>> I say that as a person who wouldn't be the one doing it ;)
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Daniel Dunbar via swift-evolution]

> 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 feature in Swift Package Manager. The 
>> proposal is available here 
>> 
>>  and also in this email:
>> 
>> Feedback welcomed!
>> 
>> Thanks,
>> Ankit
>> 
>> 
>> 
>> Package Manager Version Pinning
>> Proposal: SE-
>> Author: Daniel Dunbar , Ankit Aggarwal 
>> 
>> Review Manager: TBD
>> Status: Discussion
>> Introduction
>> This is a proposal for adding package manager features to "pin" or "lock" 
>> package dependencies to particular versions.
>> 
>> Motivation
>> As used in this proposal, version pinning refers to the practice of 
>> controlling exactly which specific version of a dependency is selected by 
>> the dependency resolution algorithm, independent from the semantic 
>> versioning specification. Thus, it is a way of instructing the package 
>> manager to select a particular version from among all of the versions of a 
>> package which could be chosen while honoring the dependency constraints.
>> 
>> Terminology
>> 
>> We have chosen to use "pinning" to refer to this feature, over "lockfiles", 
>> since the term "lock" is already overloaded between POSIX file locks and 
>> locks in concurrent programming.
>> 
> I’ve never seen this cause any actual confusion, nor has anyone I know who 
> teaches/develops these sorts of tools. As far as I can tell, the broader 
> programming community is rapidly converging on this as standard terminology:
> 
> * Gemfile.lock (Ruby)
> * Cargo.lock (Rust)
> * Composer.lock (PHP)
> * yarn.lock (JS)
> * pubspec.lock (Dart)
> * Podfile.lock (Swift/Objc!)
> 
> Diverging from this seems counter-productive.

I replied to Max on this point, can you check that?

I will add that I am completely open to being compelled by "this is becoming 
standard, we should follow".

Also, let's break this into its own fork of the thread rather than mix with the 
behavior.
>> Philosophy
>> 
>> Our philosophy with regard to pinning is that we actively want to encourage 
>> packages to develop against the latest semantically appropriate versions of 
>> their dependencies, in order to foster rapid development amongst the 
>> ecosystem and strong reliance on the semantic versioning concept. Our design 
>> for version pinning is thus intended to be a feature for package authors and 
>> users to use in crafting specific workflows, not be a mechanism by which 
>> most of the packages in the ecosystem pin themselves to specific versions of 
>> each other.
>> 
>> Use Cases
>> 
>> Our proposal is designed to satisfy several different use cases for such a 
>> behavior:
>> 
>> Standardizing team workflows
>> 
>> When collaborating on a package, it can be valuable for team members (and 
>> continuous integration) to all know they are using the same exact version of 
>> dependencies, to avoid "works for me" situations.
>> 
>> This can be particularly important for certain kinds of open source projects 
>> which are actively being cloned by new users, and which want to have some 
>> measure of control around exactly which available version of a dependency is 
>> selected.
>> 
>> Difficult to test packages or dependencies
>> 
>> Complex packages which have dependencies which may be hard to test, or hard 
>> to analyze when they break, may choose to maintain careful control over what 
>> versions of their upstream dependencies they recommend -- even if 
>> conceptually they regularly update those recommendations following the true 
>> semantic version specification of the dependency.
>> 
>> Dependency locking w.r.t. deployment
>> 
>> When stabilizing a release for deployment, or building a version of a 
>> package for deployment, it is important to be able to lock down the exact 
>> versions of dependencies in use, so that the resulting product can be 
>> exactly recreated later if necessary.
>> 
>> Proposed solution
>> We will introduce support for an optional new file Package.pins adjacent to 
>> the Package.swift manifest, called the "pins file". We will also introduce a 
>> number of new commands (see below) for maintaining the pins file.
>> 
>> This file will record the active version pin information for the package, 
>> including data such as the package identifier, the pinned version, and 
>> explicit information on the pinned version (e.g., the commit hash/SHA for 
>> the resolved tag).
>> 
>> The exact file format is unspecified/implementation defined, however, in 
>> practice it will be a JSON data file.
>> 
>> This file may be checked into SCM by the user, so that its effects apply to 
>> all users of the package. However, it may 

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

[Rob Allen via swift-evolution]

> On 14 Oct 2016, at 18:55, Daniel Dunbar via swift-build-dev 
>  wrote:
> 
>> 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:
>>> 
>>> We considered making the pinning behavior default on running swift build, 
>>> however we think that pinning by default is likely to make the package 
>>> graph more constrained than it should be. It drives the user away from 
>>> taking full advantage of semantic versioning. We think it will be good for 
>>> the package ecosystem if such a restriction is not the default behavior and 
>>> that this design will lead to faster discovery of bugs and fixes in the 
>>> upstream.
>> 
>> I agree with the others that this is the better solution.
>> 
>> With regards to the constraining problem, the key insight adopted by 
>> Cargo/Yarn/Bundler is to distinguish libraries from applications. A library 
>> shouldn’t pin its dependencies, while an application should. This ensures 
>> that the ecosystem itself is maximally unconstrained, while ensuring actual 
>> applications continue to reliably build, regardless of ecosystem changes and 
>> the computer that it was built on. If a version of a library has trouble 
>> building with different versions, it should ideally specify that with its 
>> dependency constraints, not a lock file.
> 
> This I think is one big crux of the current discussion, and one of the things 
> not in the proposal was my expectation that most packages right now are going 
> to be shared (I personally wouldn't say libraries vs applications, since 
> applications can also be shared as build tools, I think it comes down to 
> whether it is shared or not).
> 
> If we agree that a library shouldn't pin its dependencies, how would you 
> surface this feature? What exact behavior would you prefer?
> 

Bundler, Composer, Cargo & Yarn all ignore the lock file on dependencies and 
only use the one on the main build target so that they can solve the 
constraining problem. The final build target lock file does have the list of 
all exact version required for all the dependencies and sub-dependencies though 
for deterministic building of the final product. 

This only works because they all take full advantage of semantic versioning 
anyway.

I particularly like Yehuda Katz's explanation on why it works this way: 
https://github.com/yarnpkg/yarn/issues/838#issuecomment-253362537 

Regards,

Rob...


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Daniel Dunbar via swift-evolution]

> 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 start.
> 
> I also strongly agree with issues highlighted by Orta, specifically with:
> 
> > Updates to code ships bugs. Updates you don’t expect gives you bugs you 
> > didn’t expect.
> 
> I would prefer the code that compiles on CI to be exactly the same that I run 
> locally without having a need to commit all the dependencies. I also think 
> that it makes sense for this to be the default behavior.

I agree this is true for your app (actually, what I think is ideal for an app 
is that you have two branches of CI, one for your pinned dependencies and one 
with them lifted, so you are detecting incoming future regressions ASAP).

This argument doesn't work for packages being shared, because you don't control 
what your dependencies do (unless we choose to inherit pins, which has larger 
problems).

 - Daniel

> 
> With best regards, Max.
> 
> 
>> On 14 Oct 2016, at 17:43, Daniel Dunbar > > wrote:
>> 
>> 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 command as it will make builds 
>>> reproducible by default. 
>>> 
>>> I totally agree that we can rely on past experience with other package 
>>> managers (npm being the case), where pinning with a separate command caused 
>>> more harm than good.
>>> 
>>> Overall, I think that it would be great if Package.lock was created by 
>>> default when it's not present and be updated only with an explicit command 
>>> for updating.
>>> 
>>> With best regards, Max.
>>> 
>>> 
 On 14 Oct 2016, at 08:29, orta therox via swift-build-dev 
 > wrote:
 
 Please don’t make this a separate command, it should ideally be created at 
 the end of an build (when there isn’t one already) or an update of your 
 dependencies - most people will be expecting to get the same set of 
 dependencies as the rest of their team. This pattern makes that harder.
 
 NPM shrinkwrap is an example of this, and it’s a bad one - I’ve wasted a 
 lot of time trying to keep that up to date for our npm projects. Facebook 
 made a replacement for NPM with mainly the  feature of “always locking” in 
 yarn  and I’d expect that to take a lot of the JS 
 mindshare on this one feature alone.
 
 -- 
 
 [A.]   Orta Therox
 
> w/ Artsy CocoaPods  / CocoaDocs 
>  / GIFs.app 
> 
> @orta  / orta.github.com 
> 
> Artsy is totally hiring iOS Devs  
> ATM
 
> On 14 Oct 2016, at 07:01, Ankit Aggarwal via swift-build-dev 
> > wrote:
> 
> Hi,
> 
> We're proposing version pinning feature in Swift Package Manager. The 
> proposal is available here 
> 
>  and also in this email:
> 
> Feedback welcomed!
> 
> Thanks,
> Ankit
> 
> 
> 
> Package Manager Version Pinning
> Proposal: SE-
> Author: Daniel Dunbar , Ankit Aggarwal 
> 
> Review Manager: TBD
> Status: Discussion
> Introduction
> This is a proposal for adding package manager features to "pin" or "lock" 
> package dependencies to particular versions.
> 
> Motivation
> As used in this proposal, version pinning refers to the practice of 
> controlling exactly which specific version of a dependency is selected by 
> the dependency resolution algorithm, independent from the semantic 
> versioning specification. Thus, it is a way of instructing the package 
> manager to select a particular version from among all of the versions of 
> a package which could be chosen while honoring the dependency constraints.
> 
> Terminology
> 
> We have chosen to use "pinning" to refer to this feature, over 
> "lockfiles", since the term "lock" is already overloaded between POSIX 
> file locks and locks in concurrent programming.
> 
> Philosophy
> 
> 

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

[Eloy Duran via swift-evolution]

> The big struggle I have is that if we go the other direction, and as a result 
> people's semantic versions become poorly specified, we will never be able to 
> recover. The converse is not true, if we start with this direction and 
> realize it doesn't work, we can relax our behavior.

Forgot to touch on this. One interesting thing we can observe from the current 
npm/yarn split is that because npm has set the tone about trusting semver 
plenty of people will still follow this, but in my opinion it's mostly a matter 
of them not being burned *yet*.

Whatever you decide is the right thing to do now will probably cement in users 
minds for years to come, regardless of how easy it technically is to make a 
change.

(Did I say yet that I'm pessimistic about these things?)

> On 14 Oct 2016, at 18:42, Daniel Dunbar  wrote:
> 
> 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 semantic versioning.
>> 
>> While I ideally subscribe to this thought, the truth of the matter is that 
>> this has proven unreliable on multiple occasions. Promoting the idea that it 
>> works is going to inevitably lead users into problems when they did not take 
>> explicit user action to update dependencies.
> 
> This makes a lot of sense to me. The open question in my mind is, given our 
> other goals, are we in a position to make this model work, or to make it "the 
> right model for us". Some of the other things I am considering (and maybe 
> should go into the proposal):
> 
> 1. Swift is still evolving in a much greater way than other languages. That 
> means we continue to need to have a very strong push towards forward 
> versions. This is also true for the package manager features, we need the 
> ecosystem to move forward aggressively so that we can move our own features 
> forward aggressively.
> 
> 2. We have some lofty goals around semantic versioning, like trying to have a 
> much deeper integration with the compiler, API, and ABI, and testing in order 
> to help manage this more effectively.
> 
>> Semantic versioning is a great tool when you decide to sit down and 
>> explicitly update dependencies.
> 
> The problem is they go hand in hand. The more people pin versus following the 
> semantic versioning, the more and more likely it is that those specifications 
> are wrong. That leads to more pinning, which leads to more wrong 
> specifications.
> 
> My preference is that we very aggressively commit to using semantic 
> versioning, and then follow up with the entire cross functional design (an 
> index, if we ever do one, the compiler features, any IDE integration) to make 
> this work. I think we are in a better position than other tools which didn't 
> have the ability to make as many cross functional changes (e.g., integration 
> with the compiler to assist in semantic versioning).
> 
> On the other hand, I am also very pragmatic, and I respect your experience 
> here... if this model simply isn't going to work, then we shouldn't try to go 
> that way.
> 
> The big struggle I have is that if we go the other direction, and as a result 
> people's semantic versions become poorly specified, we will never be able to 
> recover. The converse is not true, if we start with this direction and 
> realize it doesn't work, we can relax our behavior.
> 
>> > We think it will be good for the package ecosystem if such a restriction 
>> > is not the default behavior and that this design will lead to faster 
>> > discovery of bugs and fixes in the upstream.
>> 
>> Again, ideally I would subscribe to this, but the truth is that when people 
>> are working on their projects they *really really really* do *not* like 
>> their builds breaking, especially not when it’s seemingly caused outside of 
>> their own fault.
> 
> One discussion we had a lot was that there are very different workflows 
> between when you are largely the consumer of packages, versus when you are 
> working on a package that is shared.
> 
> We generally agree that when you are simply the consumer of packages, pinning 
> makes sense.
> 
> However, when you are primarily a distributor of packages (and this is 
> expected to *most* of the momentum behind SwiftPM in the near term), I 
> believe that it is very important to the ecosystem that the semver specs be 
> correct, and so even if the team *wants* to pin, doing so would be actively 
> harmful.
> 
>> In the end, it comes down to whether you prioritise surfacing bugs (long 
>> term happiness) over user-experience (short term happiness). As a dependency 
>> manager author, I can tell you that I agree with your ideals and would want 
>> to choose the former, but as a user of dependency managers I would choose UX 
>> and Getting 

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

[Daniel Dunbar via swift-evolution]

> 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 automatically would 
create "Package.pins", that is the only behavior change (i.e., you don't 
inherit it from your dependencies).

Can you explain why simply needing to run one more command when you want to do 
this is a big deal? If you don't check it in, it doesn't change anything when 
you run `swift build`, that always kept a consistent set of versions. It 
changes `swift update`, but you were already running it at that point, so I'm 
not sure why that is desired.

Is it possible that we have a different expectation about what the tools do 
when you don't create this file? Our expectation is that you only ever get 
updated packages in a local build when you explicitly run `swift package 
update`. We expect to add features to notice when new dependencies are 
available, and let you choose to update, but for any one local build we are 
never talking about changing your dependencies without your interaction.

> As others have touched on, which I forgot to include, is that a library can 
> choose to not include the lock file in SCM. Especially if the lib uses a CI 
> for testing, that should bring up any issues with the latest versions of 
> dependencies while keeping a paper trail (local lock file) of dependency 
> versions that did work.
> 
> The key here is that it remains an explicit choice. The default should imo 
> always be consistent builds.

Consistent across what axis? If you don't inherit it, then you still don't get 
consistency between yourself and your clients. If you don't check it in, you 
don't get much of a behavior change. However, as is touched on in other places, 
choosing to inherit has big downsides.

> 
> 
> With regards to being in a different position, I doubt it. Swift developers 
> are, like in other languages, just humans, we all make mistakes. I think 
> we've all accepted that we'll always introduce bugs any time we have to make 
> decisions, the same applies to determining semantic versions.
> 
> You could automate some of that (e.g. check interfaces), but you cannot 
> guarantee behavioral intent and thus there's room left for human mistakes.

You can, however, in theory, apply a lot of automation for testing downstream 
dependencies (see earlier response).

> Please note, though, that I'm kinda pessimistic (realistic) about this and 
> it's solely based on experience with established ecosystems, where people 
> generally don't like being told how to do things. It may well be that your 
> situation will turn out to be different.

This is the trickiest part of this design question. We don't really know how 
the ecosystem will behave, we don't know how resilient Swift packages will be 
w.r.t. bugs and semantic versioning, etc. At the end of the day, we all just 
are sticking our fingers to the wind and hoping to do the best thing for 
everyone.

One argument I haven't heard anyone refute is that we can always back down from 
this position, but the converse isn't true (because its impact will have 
permeated the ecosystem). I consider that an important point.

> As the Queen would say, Godspeed!

:)

 - Daniel

> 
> On 14 Oct 2016, at 18:42, Daniel Dunbar  > wrote:
> 
>> 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 semantic versioning.
>>> 
>>> While I ideally subscribe to this thought, the truth of the matter is that 
>>> this has proven unreliable on multiple occasions. Promoting the idea that 
>>> it works is going to inevitably lead users into problems when they did not 
>>> take explicit user action to update dependencies.
>> 
>> This makes a lot of sense to me. The open question in my mind is, given our 
>> other goals, are we in a position to make this model work, or to make it 
>> "the right model for us". Some of the other things I am considering (and 
>> maybe should go into the proposal):
>> 
>> 1. Swift is still evolving in a much greater way than other languages. That 
>> means we continue to need to have a very strong push towards forward 
>> versions. This is also true for the package manager features, we need the 
>> ecosystem to move forward aggressively so that we can move our own features 
>> forward aggressively.
>> 
>> 2. We have some lofty goals around semantic versioning, like trying to have 
>> a much deeper integration with the compiler, API, and ABI, and testing in 
>> order to help manage 

Re: [swift-evolution] Tuples as RawRepresentable

[Karl via swift-evolution]

> On 14 Oct 2016, at 19:56, Haravikk  wrote:
> 
> Huh, see, that's why I posted the thread; I didn't know you could do it that 
> way (I've been trying the RawRepresentable part as its own type).
> In that case yes, it seems like all that's need is an expansion of what's 
> allowable on the rhs of raw value enum cases.
> 

And that’s why I come here - to share the little bits that I’ve learned :)

I think a lot of people have misconceptions about what RawRep is, and the 
inheritance syntax for enums doesn’t much help that. It doesn’t affect the 
storage or layout of the enum whatsoever; it’s just a protocol conformance. The 
compiler generates these same kind of switch statements, and that’s really the 
only reason AFAIK that we have the limitations (e.g. int/string literal) that 
we do.

There are no restrictions on what can be RawRepresentable (structs and classes 
can also conform), and no limitation on the type of RawType (can also be a 
struct or a class). You just need to implement it yourself in those cases; I’m 
guessing because there are complex edge-cases which we don’t want hidden away 
in a location you can’t easily debug.

Tuples of Ints and Strings, however, seem like they could easily be supported. 
For example, we could check that there are no overlapping cases.

- Karl

>> On 14 Oct 2016, at 18:11, Karl Wagner > > wrote:
>> 
>> Example:
>> 
>> 
>> enum something {
>> case onething
>> case anotherthing
>> }
>> extension something : RawRepresentable {
>> typealias RawValue = (Int, Int)
>> 
>> init?(rawValue: something.RawValue) {
>> switch rawValue {
>> case (1, 1):
>> self = .onething 
>> case (2, _):
>> self = .anotherthing
>> default:
>> return  nil 
>> }
>> }
>> 
>> var rawValue: (Int, Int) {
>> switch self {
>> case .onething: return (1, 1)
>> case .anotherthing: return (2, 0)
>> }
>> }
>> }
>> 
>> let whatisit = something(rawValue: (1, 1))
>> something.onething.rawValue
>> 
>> Karl
>> 
>> Sent from my iPad
>> 
>> On 14 Oct 2016, at 19:04, Karl Wagner > > wrote:
>> 
>>> You can already do this; you just need to implement RawRep manually.
>>> 
>>> What I think you mean to propose is that the compiler shorthand we have 
>>> (which synthesises the conformance if you use the equal signs next to the 
>>> cases) be extended to support tuples of the types it currently supports. 
>>> That's a relatively simple, non-source-breaking additive change. It likely 
>>> doesn't fit in the scope of swift 4 phase 1, though (sorry, I've been 
>>> guilty of chatting about non-abi stuff too as I encounter things which 
>>> irritate me; trying to be more disciplined)
>>> 
>>> Karl
>>> 
>>> Sent from my iPad
>>> 
>>> On 14 Oct 2016, at 12:55, Haravikk via swift-evolution 
>>> > wrote:
>>> 
 
> On 14 Oct 2016, at 09:49, David Sweeris  > wrote:
> 
> I'm very much in favor of the functionality, but I don't think the 
> implementation should rely on compiler magic.
> 
> - Dave Sweeris 
 
 Well it's not too much in the way of magic really, more just that we need 
 Swift to see tuples as conforming to RawRepresentable and 
 ExpressableAsTuple, although they currently aren't types in the normal 
 sense. So the protocols being used will be the same as you might use 
 yourself, they'll just be applied automatically for tuples.
 
 It'd be neat if it could be done properly, but that could involve even 
 more work, but doing this automatically for now should be fairly simple 
 (though I say that as a person who wouldn't be the one doing it ;)
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Daniel Dunbar via swift-evolution]

> 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 application should.
> 
> Not only “shouldn’t” but can’t: Rust’s cargo (I don’t know for sure about 
> Bundler and Yarn, but they’re all in the same vein, and pretty much from the 
> same person) will just ignore any non-top-level lock files, i.e. the package 
> that user is working on has a record of the exact versions of everything in 
> their dependency graph, and the user can update all or just parts of that 
> graph fairly precisely, as desired.
> 
> My impression is that other ecosystems without pinning-by-default have 
> seriously suffered from the lack of reliable reproducible builds. For 
> instance, a major complaint I have seen about "go get” is that one can come 
> back to some code after a few months to fix a minor bug and have no chance of 
> getting the code to compile, basically just requiring a full rewrite, because 
> dependencies' code has changed (or disappeared entirely) and there’s no 
> record of what the original was, despite your code being completely untouched 
> in all that time.

This wouldn't have been our behavior under this proposal, unless you recloned 
the package. Maybe that is what you meant though?

> Of course, a hard push towards API-level semantic versioning may allay the 
> worst of the code-changing problems, but unless there’s going to be some 
> seriously fancy static analysis (something something halting problem), there 
> will be a lot of breaking changes that can’t be picked up.
> 
> ---
> 
> To reframe the discussion slightly, not pinning dependencies effectively 
> means that the tools are making “random" changes to your code outside your 
> control. Sure, those changes were transitively made by 
> possibly-computer-assisted humans and may fix bugs, but those pesky meat-bags 
> can still make mistakes, and, they don’t see the interactions between all the 
> different packages in your specific application.
> 
> IME having the predictability of “never changing code under my feet” combined 
> with pervasive semantic versioning hits an empowering middle ground of being 
> able to depend on many & varied packages and update them to the latest 
> versions without fear (for one, it’s easy to revert the lock file if 
> something breaks during an update). Feedback from others about cargo is the 
> same, often along the lines of “it’s the best package manager I’ve ever used”.

To be clear, exactly when are you expecting the tools to "change code under my 
feet".

In our design, the only time we ever change a *local build* is in response to 
an explicit user action, so we aren't changing code under your feet necessarily.

If you throw away a checkout, and fetch it again, then yes we get a different 
version. Is this the use case you are talking about (and by implication talking 
about committing the file)?

If you reset your local workspace completely, then yes we will get a different 
version (since we had to reclone).

I just want to make sure it is clear to everyone that we are not proposing we 
automatically change your build version underneath you any time we happen to 
fetch something new from the package. We only update in response to user action.

> Also, more on the side of implementation details, having a lock file by 
> default probably mean one can (get closer to) never hitting the network 
> unless the user asks for it, making working offline or on a 
> low-speed/high-latency connection easier, i.e. no need to check for new 
> versions of the whole dependency graph on O(every) build, which aggressively 
> keeping everything up to date would seemingly have to do? (I don’t know 
> swift-pm’s current behavior here, so maybe there’s some tricks that avoid it.)

This is part of the proposed design (this is the current implementation, 
really), FWIW, although that may not have been clear at all.

 - Daniel

> 
> Huon
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Eloy Durán via swift-evolution]

>> Totally 
> 
> I'm not sure what this is to. :)

You and me both… Guess I must have lost track of my thought here while trying 
to respond from my phone and playing with the baby in between.

> Pin by default in the sense you are using it just means we automatically 
> would create "Package.pins", that is the only behavior change (i.e., you 
> don't inherit it from your dependencies).
> 
> Can you explain why simply needing to run one more command when you want to 
> do this is a big deal?

It’s clearly not a big deal in amount of work, what it comes down to is setting 
an example. If you, as an authority, make it the default option to not pin, 
then to many people that will signal that that’s The Right Thing to do.

> Is it possible that we have a different expectation about what the tools do 
> when you don't create this file?

No, it’s a philosophical difference in thinking about dependencies.

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, trusting them to properly apply SemVer is the same 
issue.

My worst nightmare is people updating dependencies and getting lazy in vetting 
them, a mindset that is in my observation the status quo in e.g. npm, a 
dependency manager which makes it the default to not pin and trust SemVer. On 
the other hand, the laziness might also be compounded by the micro-lib norm, 
it’s not unusual for npm packages to have a dependency graph of dozens, if not 
hundreds of packages.

This also leads me to the following point you bring up:

> One argument I haven't heard anyone refute is that we can always back down 
> from this position, but the converse isn't true (because its impact will have 
> permeated the ecosystem). I consider that an important point.

The reason I would not try to refute it is A) simply because it’s true and B) 
it’s, to me, more of a technicality that’s moot in contrast to my philosophical 
thoughts, as explained above.

One final note, playing the devil’s advocate against my own opinion, seeing as 
you are at a place where you can try it and later change, I’d say do it. 
However, it might be a good idea to document the possibility of this changing 
in the future, just so expectations are set correct and the thought to keep an 
eye on this is kept alive in the community.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ryan Lovelett via swift-evolution]

> I particularly like Yehuda Katz's explanation on why it works this
> way: https://github.com/yarnpkg/yarn/issues/838#issuecomment-253362537

This was a powerful description for me. @Rob thank you for
providing that!

 1. The articulation of the purpose/philosophy behind the whole thing
was really clear and made sense to me. Even though I've never
used Rust or Cargo. Nor have I ever run into any problems with
npm such that I would prefer yarn over it. I've used Bundler for
years and love it.
 2. Yehuda Katz has been involved in making 3 different package managers
for 3 different communities/languages over at least a 6-year span.
It feels trite but it seems likely he has knowledge/experience we
might not. It might be wise to seriously consider the wisdom of
others with experience.

I will say that like others on this thread prefer determinism in
my builds.

Whatever path leads me there is the path I want to walk. I'm not smart
enough to say if this proposal will preclude that or not. I am moved by
the notion that there are successful package managers out there as
examples which today achieve that goal.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Daniel Dunbar via swift-evolution]

> 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 the connotation actually 
>> works fairly well (e.g., a pinboard is something you pin to while working, 
>> or pinning a dress while you stitch it). I also wasn't a huge fan of pin 
>> initially, but as it bounced around in my head for a while I really started 
>> to like it, for exactly this connotation reason.
> 
> I think this comment drives at the core of the difference between this 
> proposal and what Orta, Alexis and others are saying. (At least for me)
> 
> The description you've provided here, specifically the word "workflow", and 
> the concept of operations described by the proprosal are meant to be a 
> transient. They are meant as a temporary description of how these 
> dependencies should be kept in order.  To my mind one "puts a pin" in 
> something temporarily. To comeback to it later to do something with it at 
> that time. Thus the pin probably does work with this concept.
> 
> Conversely, the concept of "locking" something feels less transient. It feels 
> more permanent. More like the concept of operations described by Orta, Alexis 
> and others. Idle speculation: might be why those other managers selected the 
> word lock.
> 
> Not sure where I come down on the whole thing yet. Just wanted to say that if 
> the propsal goes another way than what was first propsed a new word likely 
> should be investigated.

I agree with everything here. :)

 - Daniel

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution