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

> Am 03.11.2016 um 03:22 schrieb Daniel Duan : > On Nov 2, 2016, at 3:46 PM, Martin Waitz via swift-evolution > wrote: > >>> What is your evaluation of the proposal? >> >> +1 for using reproducible versions of dependencies >> -1 for the actual

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

Daniel Duan Sent from my iPhone On Nov 2, 2016, at 11:17 PM, Martin Waitz wrote: >> Am 03.11.2016 um 03:22 schrieb Daniel Duan : >> On Nov 2, 2016, at 3:46 PM, Martin Waitz via swift-evolution >> wrote: >> What is your

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

> Am 03.11.2016 um 03:22 schrieb Daniel Duan : > > On Nov 2, 2016, at 3:46 PM, Martin Waitz via swift-evolution > wrote: > >>> What is your evaluation of the proposal? >> >> +1 for using reproducible versions of dependencies >> -1 for the actual

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

Could you specify that in the tag of the dependency you need? >= 3.0.0 vs = 2.0.0 etc... I am not sure why in some cases we need to be unique over state of the art like Cocoapods in some areas. What is the added value (not saying that there is none)? Sent from my iPhone > On 3 Nov 2016,

Re: [swift-evolution] guard let x = x

As pleasing as it sounds*), the idea of type narrowing breaks down badly if: – the binding is implicit (without explicit extra syntax involved) and – what is bound happens to be mutable. An example being: // var message: String? if message != nil { // magic turns 'message' into a

Re: [swift-evolution] guard let x = x

> if x != nil { > // x is definitely not nil inside this block (implicitly > unwrapped) Pyry already mentioned the problem that arise when x is a variable (is "x = nil" forbidden inside the block?). Properties add complications as well (especially, but not only, computed ones),

Re: [swift-evolution] guard let x = x

Am 2016-11-03 09:17, schrieb Pyry Jahkola via swift-evolution: As pleasing as it sounds*), the idea of type narrowing breaks down badly if: – the binding is implicit (without explicit extra syntax involved) and – what is bound happens to be mutable. An example being: // VAR message: String?

Re: [swift-evolution] [Pitch] Make `errno`-setting functions more usable from Swift

Hi John, > [...] >> This is a pitch to make [`errno`][1]-setting functions properly usable, as >> in having a guarantee to get the correct `errno` value on failure of a >> [system call][2]. Currently, functions which set `errno` are just exported >> in the Darwin/Glibc modules with (as far as

Re: [swift-evolution] guard let x = x

> On 3 Nov 2016, at 08:17, Pyry Jahkola wrote: > > As pleasing as it sounds*), the idea of type narrowing breaks down badly if: > > – the binding is implicit (without explicit extra syntax involved) and > – what is bound happens to be mutable. > > An example being: > >

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

Has anybody thought about the semantic issues of out-of-module extensions with stored properties apart from the implementation issues? Such properties could potentially wreak havoc with the semantics of the type being extended. How would these properties play nice with an existing definition

Re: [swift-evolution] [Review] SE-0143: Conditional Conformances

> On Nov 2, 2016, at 4:39 PM, Martin Waitz via swift-evolution > wrote: > > Hi, > >> The review of “Conditional Conformances” begins now and runs through October >> 7. > > What’s the status here? > My impression is that it’s quite uncontroversial and everybody

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

> On Nov 3, 2016, at 1:02 AM, Goffredo Marocchi wrote: > > Could you specify that in the tag of the dependency you need? >= 3.0.0 vs > = 2.0.0 etc… That’s missing the point of pinning though. You can already do this in Package.swift. Pinning is, in a way, guarding

[swift-evolution] [Proposal] Type Narrowing

To avoid hijacking the guard let x = x thread entirely I've decided to try to write up a proposal on type narrowing in Swift. Please give your feedback on the functionality proposed, as well as the clarity of the proposal/examples themselves; I've tried to keep it straightforward, but I do tend

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

> On 3 Nov 2016, at 17:36, Daniel Duan via swift-evolution > wrote: >> I am not sure why in some cases we need to be unique over state of the art >> like Cocoapods in some areas. What is the added value (not saying that there >> is none)? > > You can combine

Re: [swift-evolution] [Proposal] Type Narrowing

Great. I'd like to see something like this. Couple of comments: You don't explicitly address overload selection. Do you intend it to be affected? Impact on existing code section could be more descriptive. On Thursday, November 3, 2016, Haravikk via swift-evolution < swift-evolution@swift.org>

[swift-evolution] Sort Descriptors

Hey everyone, I was wondering if there's any interest in adding Swift-like sort descriptors to the language. Currently, we have `sort` and `sorted`, which take a function of type `(A, A) -> Bool`. Foundation has `NSSortDescriptor`, which corresponds more to `(A, A) -> ComparisonResult`.

Re: [swift-evolution] [Proposal] Type Narrowing

This proposal seems well-reasoned, but like Nevin I worry about the interactions between type narrowing, reference types or capture of mutable values, and concurrency or async. How will these things play together? On Thu, Nov 3, 2016 at 14:23 Nevin Brackett-Rozinsky via swift-evolution <

Re: [swift-evolution] Sort Descriptors

> On 2016-11-03, at 19:39, Chris Eidhof via swift-evolution > wrote: > I was wondering if there's any interest in adding Swift-like sort descriptors > to the language. Currently, we have `sort` and `sorted`, which take a > function of type `(A, A) -> Bool`.

Re: [swift-evolution] [Proposal] Type Narrowing

> On 3 Nov 2016, at 19:23, Nevin Brackett-Rozinsky > wrote: > For the motivating examples, there is already a much cleaner solution: > (foo as? B)?.someMethodSpecificToB() Eh, kinda; you've taken an example showing branching and boiled it down into a single

Re: [swift-evolution] [Proposal] Type Narrowing

Okay, I think I found an actual shortcoming that type narrowing might address, namely mutating a property in place if it is a subtype. Here is a small example setup: protocol A { var x: Int {get} } struct B: A { var x: Int } struct C { var a: A } var c = C(a: B(x: 4)) Note that “A” does not

Re: [swift-evolution] guard let x = x

vars cannot be type narrowed as soon as concurrency comes into play. That's why Ceylon restricts type narrowing to immutables. -Thorsten > Am 03.11.2016 um 09:52 schrieb Martin Waitz via swift-evolution > : > > Am 2016-11-03 09:17, schrieb Pyry Jahkola via