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 evaluation of the proposal? >>> >>> +1 for using reproducible vers

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 proposal >> >> My problem with this proposal is th

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

> On Nov 2, 2016, at 2:02 PM, Matthew Johnson via swift-evolution > wrote: >> On Nov 2, 2016, at 3:47 PM, Sean Heber via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> For what it’s worth, I concur. I think type narrowing makes it feel more >> like the language is actually

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

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 proposal > > My problem with this proposal is that it tries to please everybody by > introducing options e

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

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 can’t wait to see this implemented :-) -- Martin ___ swift-evolution mailin

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

> What is your evaluation of the proposal? +1 for using reproducible versions of dependencies -1 for the actual proposal My problem with this proposal is that it tries to please everybody by introducing options everywhere. I think we should try to build a system which is robust and works all of

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

> On Nov 2, 2016, at 6:12 AM, Johannes Weiß via swift-evolution > wrote: > Hey swift-evolution, > > First of all apologies, this is not a full proposal yet, it's meant to kick > off a discussion on how to resolve the issue. > > # Make `errno`-setting functions more usable from Swift > > ## In

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

> On Nov 2, 2016, at 3:47 PM, Sean Heber via swift-evolution > wrote: > > For what it’s worth, I concur. I think type narrowing makes it feel more like > the language is actually doing some work *for* me rather than me having to > babysit the language with some new syntax or keyword. I’ve be

[swift-evolution] Forbid weak keyword for computed properties

Hello everyone! I originally did a mistake by posting it directly to github, passing swift-evolution mailing list step. But better late, than never, right? I wish I can get more feedback on my proposal here: https://github.com/apple/swift-evolution/pull/528

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

For what it’s worth, I concur. I think type narrowing makes it feel more like the language is actually doing some work *for* me rather than me having to babysit the language with some new syntax or keyword. l8r Sean > On Nov 2, 2016, at 3:25 PM, Haravikk via swift-evolution > wrote: > > I s

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

I still think that type narrowing is the right way to handle this like so: if x != nil { // x is definitely not nil inside this block (implicitly unwrapped) } // x remains optional outside of it if (x != nil) || (x == y) { // if y's type is

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

> On Nov 2, 2016, at 8:32 AM, Paul Cantrell wrote: > > >> On Oct 24, 2016, at 4:43 PM, Slava Pestov wrote: >> >> >>> On Oct 24, 2016, at 8:12 AM, Paul Cantrell wrote: >>> >>> On Oct 24, 2016, at 5:09 AM, Slava Pestov via swift-evolution wrote: However protocols nest

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

I think I agree with Tino, the use-case of “unwrap” for shadowing is not compelling enough to justify adding a keyword. Moreover, regarding the generalized enum associated-value extraction situation, the approach I described earlier is copacetic to both destructuring tuples and leaving them intact

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

> > * What is your evaluation of the proposal? +1 > * Is the problem being addressed significant enough to warrant a change > to Swift? Yes, version pinning is very important to dependency management in production environments. > * Does this proposal fit well with the feel

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

Imho it would be better not to add "uwrap". Yes, it might be nicer in some situations, but it is also nice to have a simple (or at least less complicated) language. For me, the actual benefit is to low to justify a separate keyword which creates questions that don't exist with the current syntax.

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

> Am 01.11.2016 um 19:42 schrieb Erica Sadun via swift-evolution > : > > Here are a few varieties of how that call might look versus the proposed > update for normal pattern matching: > > if unwrap .string(myString) ~= json { ... } > if unwrap .contact(code, _) ~= response { ... } > if unwrap

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

> On Oct 24, 2016, at 4:43 PM, Slava Pestov wrote: > > >> On Oct 24, 2016, at 8:12 AM, Paul Cantrell wrote: >> >> >>> On Oct 24, 2016, at 5:09 AM, Slava Pestov via swift-evolution >>> wrote: >>> >>> However protocols nested inside types and types nested inside protocols is >>> still not

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

I could see the "swift_error" Clang attribute being extended with an "errno" case (in the same vein as "nonzero_result" and "zero_result"), which is then reflected into Swift via the importer. Although, having an attribute for methods set errno seems like it would be useful for the Clang Analyzer o

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

Hey swift-evolution, First of all apologies, this is not a full proposal yet, it's meant to kick off a discussion on how to resolve the issue. # Make `errno`-setting functions more usable from Swift ## Introduction This is a pitch to make [`errno`][1]-setting functions properly usable, as in

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

> Le 1 nov. 2016 à 14:42, Erica Sadun via swift-evolution > a écrit : > > With massive revisions. I've added Xiaodi Wu to author list. I've combined > all unwrapping together. I've added a much more sensible approach (plus a > bluesky one) for real world enumerations. > > Gist with live upda