[swift-evolution] Draft of proposal for autoreleasepool signature change

rg/pipermail/swift-evolution/Week-of-Mon-20160321/013059.html>. Jordan Rose pointed out <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013077.html> that care was needed to avoid inferring an incorrect return type for the body block, but after testing w

Re: [swift-evolution] [Idea] Add forced conversion for Error catching pattern matching

> do { > let action = chooseAction(game) > game = try game.applyAction(action) > } catch let e as ActionError { > game.failedAction = e > } catch _ { > fatalError(“This is an unfortunate bit of noise :/") > } If you're just worried about the noise... try! {

Re: [swift-evolution] [Draft] Abolish IUO type

On Mar 18, 2016, at 11:36 AM, Chris Willmore via swift-evolution wrote: >> typedef void (^CallbackBlock)(FDataSnapshot *snapshot); >> >> The parameter in the block gets converted into a IUO, I ended up releasing >> an app that crashed due to that IUO being nil. >>

Re: [swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

I believe the scoped @discardableResult(warn|critical) attribute is a nice idea for future directions, but I'm not sure it's in scope of this proposal, which, as a first small step, aims to basically invert the @warn_unused_result standard. cc Erica Pozdrawiam – Regards, Adrian Kashivskyy >

Re: [swift-evolution] [swift-build-dev] Proposal Discussion Thread: SwiftPM: Locking and Overriding Dependencies

I have revised the proposal based on feedback: https://github.com/mxcl/swift-evolution/blob/lockfiles/proposals/-swiftpm-dependency-lockfiles.md Changed location and name, included SHAs, revised build-workflow steps. ___ swift-evolution mailing

Re: [swift-evolution] Proposal Discussion Thread: SwiftPM: Locking and Overriding Dependencies

> 2. I like VersionLocks.json well enough, but would like to see a discussion > about possible alternatives. My personal proposal (in line with #1) is to use > "PackageVersions.json" which has a nice agreement with Package.swift and > would mean two common metadata files show up adjacent. I

Re: [swift-evolution] [swift-build-dev] Proposal Discussion Thread: SwiftPM: Locking and Overriding Dependencies

> - update Manifest.swift file. There is no convent way to do it now. It is not convenient enough to edit it with a text editor and commit? Seems pretty convenient to me. ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] Pre-proposal: Safer Decimal Calculations

I still absolutely think the best proposal for this is to add a Fraction type to the standard library with easy conversions to and from all the numeric types. Your precision is only limited by the size of IntMax, and you can do whatever operations you want without losing precision. There’s a

Re: [swift-evolution] Should all GeneratorTypes also be SequenceTypes?

on Mon Mar 14 2016, Dmitri Gribenko wrote: > On Mon, Mar 14, 2016 at 4:42 PM, Haravikk via swift-evolution > wrote: >> There are quite a lot of generator implementations that also >> implement SequenceType (since it’s as simple as returning

Re: [swift-evolution] struct subtyping

+1 On Monday, 21 March 2016, Tino Heth via swift-evolution < swift-evolution@swift.org> wrote: > Many languages which adopt the concept of value types don't allow > subclassing for those, and so does Swift. > Inheritance for structs is more complex than inheritance for classes, but > the "final"

Re: [swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

> On 21 Mar 2016, at 20:35, Erica Sadun via swift-evolution > wrote: > In Swift Evolution discussions, the term @discardable was mildly preferred > over @discardableResult. > > Some community members requested a new attribute enabling exceptional > imported

Re: [swift-evolution] Making pointer nullability explicit (using Optional)

I'm not sure what you mean by this. (I think we agree, but I'm not sure.) A null pointer (in C) is not a pointer with a zero representation; it's a pointer that is guaranteed not to point to any valid object. By using Optional, Swift gets that value out of the type called "pointer", but can

Re: [swift-evolution] [swift-build-dev] Proposal Discussion Thread: SwiftPM: Locking and Overriding Dependencies

I like the proposal. I have 1 concern. As a package author, like PromiseKit I often have a need to fix some of my dependencies and publish it to my package users. With the current proposal I can do it: - Advise it in README, which is not really a

[swift-evolution] Swift 2.2 released!

Hi everyone, I am very pleased to announce the release of Swift 2.2! This is the first release of Swift since Swift became an open source project. Swift 2.2 began it’s convergence in mid-January when it branched from master, and since then is had taken curated changes (bug fixes and some

Re: [swift-evolution] [proposal] Generic type aliases

Ok I read all the previous posts and I’m totally fine with this feature as it’s mentioned in its base form. Looking forward to see generic typealias allowing type constraints. There is one thing still on my mind: how do we use a generic typealias? typealias SomeTuple = (T, T) func foo(tuple:

Re: [swift-evolution] [Idea] Add forced conversion for Error catching pattern matching

> > On Mar 21, 2016, at 6:01 AM, Haravikk wrote: > > I’m a ±1; for the way things are I’m a +1, but I think I’d still prefer to > have typed errors that the compiler can use to check for an exhaustive list, > as it would be easy for a forced conversion to result

Re: [swift-evolution] Update the signature of ObjectiveC.autoreleasepool [SR-842]

> On Mar 21, 2016, at 11:43, Dmitri Gribenko wrote: > > On Mon, Mar 21, 2016 at 9:37 AM, Jordan Rose wrote: >> -1 for the signature change. The most common case of autoreleasepool does >> not return a value and has a multi-statement body that

Re: [swift-evolution] Making pointer nullability explicit (using Optional)

> On Mar 19, 2016, at 10:36, Chris Lattner wrote: > > > On Mar 18, 2016, at 9:49 AM, Jordan Rose via swift-evolution > > wrote: > >> >>> On Mar 17, 2016, at 21:08 , Russ Bishop >>

Re: [swift-evolution] [Idea] ObjectiveCBridgeable

> On Mar 9, 2016, at 12:26 PM, Russ Bishop via swift-evolution > wrote: > > An official proposal PR has been opened on this: > https://github.com/apple/swift-evolution/pull/198 > > > It includes clarifications, a

Re: [swift-evolution] Update the signature of ObjectiveC.autoreleasepool [SR-842]

-1 for the signature change. The most common case of autoreleasepool does not return a value and has a multi-statement body that prevents the result type from being inferred. This needs to continue to work: autoreleasepool { foo() bar() } If we had a rule to default generic return values

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

> On 21 Mar 2016, at 17:05, ted van gaalen wrote: > > Hello Taras > Please take a look here: > https://en.m.wikipedia.org/wiki/For_loop > > > More than 30 ! programming languages since 1957 until now, have their >

Re: [swift-evolution] Update the signature of ObjectiveC.autoreleasepool [SR-842]

> On Mar 20, 2016, at 11:41 PM, Dmitri Gribenko wrote: > > On Sun, Mar 20, 2016 at 9:32 PM, Timothy Wood via swift-evolution > wrote: >> >> In preparation for writing a proposal, I wanted to solicit any feedback and >> general level of interest

Re: [swift-evolution] Pre-proposal: Safer Decimal Calculations

> On 20 Mar 2016, at 17:54, Rainer Brockerhoff via swift-evolution > wrote: > > On 3/20/16 14:43, Andrey Tarantsov via swift-evolution wrote: >> I have no stake in this proposal, except for: >> >>> I suggest, therefore, that this acceptance be indicated by an >>>

Re: [swift-evolution] [Idea] Add forced conversion for Error catching pattern matching

> Also as a brief aside, it’s not super intuitive to me that the syntax for the > catch pattern matching wildcard is > > catch _ > > whereas it is > > default > > for switches. I do believe you can just say `catch`: 4> do { 5. try throwing() 6. } catch let e as E { ... 7. }

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

To be honest, I have difficulty understanding the premise of this discussion. I have always found the C-style for(;;) loop an awkward construct, because it is essentially just an alternative form of writing a general-purpose while loop. It is perfectly reasonable to restrict the for construct

Re: [swift-evolution] [Idea] Add forced conversion for Error catching pattern matching

I’m a ±1; for the way things are I’m a +1, but I think I’d still prefer to have typed errors that the compiler can use to check for an exhaustive list, as it would be easy for a forced conversion to result in unexpected runtime errors later if you ever need to add a new error type to your

[swift-evolution] [Review] SE-0042 Flattening the function type of unapplied method references

Sorry for being late! I am not quite sure! Although I believe that this is a step in the right direction (inout parameters), I would like to see a more general approach where the unapplied method reference produces not one but ALL possible references! That means that taking the unspecified

Re: [swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

> On Mar 16, 2016, at 11:46 PM, Adrian Kashivskyy via swift-evolution > wrote: > > @Jed, > >> That said, the problem isn’t necessarily difficult to solve — it’s just that >> it’s important that it actually be solved at the same time the feature is >> rolled out. >

Re: [swift-evolution] [Idea] Add forced conversion for Error catching pattern matching

> On Mar 20, 2016, at 1:26 PM, Tyler Fleming Cloutier via swift-evolution > wrote: > > Also as a brief aside, it’s not super intuitive to me that the syntax for the > catch pattern matching wildcard is > > catch _ > > whereas it is > > default > > for