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

2016-10-14 Thread 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

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

2016-10-14 Thread 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.

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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,

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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: >>

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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. > *

Re: [swift-evolution] private & fileprivate

2016-10-14 Thread 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”

[swift-evolution] Tuples as RawRepresentable

2016-10-14 Thread 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

Re: [swift-evolution] private & fileprivate

2016-10-14 Thread 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

Re: [swift-evolution] Tuples as RawRepresentable

2016-10-14 Thread 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

Re: [swift-evolution] Tuples as RawRepresentable

2016-10-14 Thread 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,

Re: [swift-evolution] private & fileprivate

2016-10-14 Thread 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

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

2016-10-14 Thread 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

Re: [swift-evolution] private & fileprivate

2016-10-14 Thread 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

Re: [swift-evolution] private & fileprivate

2016-10-14 Thread 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

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

2016-10-14 Thread 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.

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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. >> >>

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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,

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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: > > >

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread Jose Cheyo Jimenez via swift-evolution
> On Oct 14, 2016, at 12: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: > > >

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

2016-10-14 Thread 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 >>

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

Re: [swift-evolution] private & fileprivate

2016-10-14 Thread 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”).

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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. //

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

2016-10-14 Thread 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. :)

Re: [swift-evolution] private & fileprivate

2016-10-14 Thread 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

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

2016-10-14 Thread 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".

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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:

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

[swift-evolution] Proposal: Package Manager Version Pinning

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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 >>>

Re: [swift-evolution] private & fileprivate

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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,

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

2016-10-14 Thread 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: >

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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:

Re: [swift-evolution] Tuples as RawRepresentable

2016-10-14 Thread 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, _):

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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 >

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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 > >

Re: [swift-evolution] Tuples as RawRepresentable

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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 >

Re: [swift-evolution] Tuples as RawRepresentable

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

Re: [swift-evolution] Tuples as RawRepresentable

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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

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

2016-10-14 Thread 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