-1, though I do strongly think we should have version pinning.
I agree with the others who believe that dependencies should be pinned by
default. This doesn't mean that you have to check the pin/lock file into
source control. I have a good amount of experience developing apps and
libraries with
You can currently achieve the same result if you remove `[inout a]` since
`var`s are captured by reference.
On Wed, Oct 5, 2016 at 9:06 PM, Cao Jiannan via swift-evolution <
swift-evolution@swift.org> wrote:
> for example:
>
> var a = 1
>
> let block = { [inout a] in
> a += 1
> }
>
>
It's weird to me that protocol-typed objects aren't seen as conforming to
that protocol. I would intuitively expect this function to work for both a
sequence of Pepper types and other types that conform to Pepper:
func pick(peppers: PepperType) where
PepperType.Iterator.Element:
Pepper {
//
>
> Modules names are tied to a directory structure that describes their
> location relative to the current module and it will now be an error to
> violate this rule
What is the rationale for this rule? I realize this is a common convention
but what is gained from strictly enforcing it?
On Mon,
Forbidding custom `==` for value types would break equality for all Swift
collection types, since they use reference types behind the scenes for
storing memory and copy on write semantics. Furthermore, why should
properties pointing to reference types always use `===`? What if the
reference type
>
> What is your evaluation of the proposal?
>
+1
> Is the problem being addressed significant enough to warrant a change to
> Swift?
>
Yes, the current situation of defining a protocol required operator
function globally is potentially confusing and feels inconsistent.
> Does this proposal
>
> What is your evaluation of the proposal?
>
+1
Is the problem being addressed significant enough to warrant a change to
> Swift?
>
Yes. Passing value types to Objective-C APIs taking AnyObject requires
creating wrapper classes that store the value types. This change would
eliminate that
I also disagree for the same reasons that Gwynne and Brent mentioned: I
find '\(...)' easy to read, fine to type, and consistent with other string
escaping syntax.
On Tue, Jun 21, 2016 at 3:55 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:
> > I find that typing
