Re: [swift-evolution] [pitch] adding toggle to Bool

Bool { > >> @discardableResult > >> func whenTrue(execute closure: () throws -> T) rethrows -> T? { > >>if self { return try closure() } > >>return nil > >> } > >> > >> @discardableResult > >> func whenFalse(execute

[swift-evolution] [pitch] adding toggle to Bool

Hey SE! When we have a bunch of nested structs: struct Sample { var bar: Bar } struct Bar { var show: Bool } var foo = Sample(bar: Bar(show: false)) It can be repetitive to toggle a deeply nested boolean: foo.bar.show = !foo.bar.show // duplication I

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

I can see why this is useful, and understand the problem. However, it does feel like the wrong solution to a real problem. This seems to be very similar to the *expression problem*: > The expression problem is a new name for an old problem.[2][3] The goal is to define a datatype by cases, where

Re: [swift-evolution] Removing enumerated?

I agree that it's very useful. I use it regularly. The documentation isn't that unclear, imo. To me, the underlying problem isn't enumerated. I think the underlying cause is that collections aren't indexed with zero based indices.if you don't understand this (which is the case for many experienced

[swift-evolution] Removing enumerated?

Hey everyone, I've organized a number of Swift workshops over the last two years. There are a couple of things that keep coming up, and a couple of mistakes that I see people making over and over again. One of them is that in almost every workshop, there's someone who thinks that `enumerated()`

[swift-evolution] Generalized Existentials / Type Erasers

Hi swift-evolution, I was wondering if anything more detailed has been written about generalized existentials / type erasers. I noticed that AnyCollection only delegates a number of methods to its wrapped value, but often doesn't. For example, all the conditionally inherited items aren't being

Re: [swift-evolution] Strings in Swift 4

mpiler engineer), so hopefully my pessimism is unjust. On Wed, Jan 25, 2017 at 7:23 PM, Joe Groff <jgr...@apple.com> wrote: > > On Jan 24, 2017, at 9:35 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > > On Jan 24, 2017, at 12:05 AM, Chris

Re: [swift-evolution] Strings in Swift 4

output of the lhs. To me it seems like there's a lot of (exciting) work to be done to get this right :). On Wed, Jan 25, 2017 at 6:35 AM, Chris Lattner <sa...@nondot.org> wrote: > On Jan 24, 2017, at 12:05 AM, Chris Eidhof via swift-evolution < > swift-evolution@swift.org> wr

Re: [swift-evolution] Reduce with inout

I like it too! Thanks Pyry! Will change the proposal. On Wed, Jan 25, 2017 at 8:09 AM, David Hart via swift-evolution < swift-evolution@swift.org> wrote: > Yep, that's really good. > > On 25 Jan 2017, at 08:00, Jonathan Hull via swift-evolution < > swift-evolution@swift.org> wrote: > > +1 Best

Re: [swift-evolution] Strings in Swift 4

Hey Matthew, Do you have an example of doing parser combinators without FP? I'd be very interest On Tue, Jan 24, 2017 at 4:52 PM, Matthew Johnson <matt...@anandabits.com> wrote: > > On Jan 24, 2017, at 2:05 AM, Chris Eidhof via swift-evolution < > swift-evolution@swift.org&g

Re: [swift-evolution] Reduce with inout

oint.init(signOf:magnitudeOf:)`. > > On Tue, Jan 24, 2017 at 07:33 Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> >> Sent from my iPad >> >> On Jan 24, 2017, at 1:54 AM, Chris Eidhof via swift-evolution < >> swi

Re: [swift-evolution] Strings in Swift 4

I agree that being able to implement parsers in a nice way can be a huge step forward in being really good at string processing. There are a couple of possibilities that come to mind directly: 1. Build parsers right into the language (like Perl 6 grammars) 2. Provide a parser combinator language

Re: [swift-evolution] Reduce with inout

I've thought about it for a few days, and really like `reduce(mutating:_)`. I've updated the PR, and am now happy for this to go into review. https://github.com/apple/swift-evolution/pull/587 On Mon, Jan 23, 2017 at 8:27 AM, Russ Bishop wrote: > > On Jan 22, 2017, at 10:56

Re: [swift-evolution] Reduce with inout

To me, that sounds more like a monomorphic map? (i.e. a `map` that doesn't change the type). On Mon, Jan 23, 2017 at 10:07 AM, Jonathan Hull wrote: > While we are at it, could we add a inout/mutating version of forEach > (unless something like that exists and I missed it)? I

Re: [swift-evolution] Reduce with inout

Not as a direct reply to Russ, but just to reiterate: to me, there are two clear benefits of using the `inout` version of reduce: 1. The performance (currently discussed at length) 2. Readability (because we can use mutating methods on `inout` arguments). Even if the compiler were to optimize

Re: [swift-evolution] [Review] SE-0148 Generic Subscripts

Hey all, I've added a PR which consists of two commits: one that mentions more examples, and one that adds a note about including default arguments. On Fri, Jan 20, 2017 at 7:32 AM, Russ Bishop via swift-evolution < swift-evolution@swift.org> wrote: > > > On Jan 19, 2017, at 5:04 PM, Slava

Re: [swift-evolution] Reduce with inout

I think the nice thing about reduce is that you can use it to implement something in a single line, and directly return it. Making the first parameter inout would require you to write `var result = ` and `return result` (and `result` will be mutable after the call to `reduce`). Typically, the

Re: [swift-evolution] Reduce with inout

I opened up a WIP PR on the SE repository (so many TLA's!). https://github.com/apple/swift-evolution/pull/587 I think I'll wait a few days before removing `WIP` until the naming discussion either reaches consensus or settles down. So far, I would summarize the thread as: people are in favor, but

Re: [swift-evolution] Reduce with inout

I don't think we should replace the current `reduce` with the `inout` version, also because the current reduce can be really useful as well (e.g. when the return type is an Int). One downside of having a different name is that it'll be harder to discover this version. If stressing the

Re: [swift-evolution] Reduce with inout

Jan 16 2017, Charles Srstka <swift-evolution@swift.org > >>> <mailto:swift-evolution@swift.org>> wrote: > >>> > >> > >>>>> On Jan 16, 2017, at 7:49 AM, Chris Eidhof via swift-evolution < > swift-evolution@swift.org> wrote: >

[swift-evolution] Reduce with inout

Hi, How does everyone feel about adding a second version of `reduce` to `Sequence`? Instead of a `combine` function that's of type `(A, Element) -> A`, it would be `(inout A, Element) -> ()`. This way, we can write nice functionals algorithms, but have the benefits of inout (mutation within the

Re: [swift-evolution] Generic Subscripts

I agree with Dave. To me, building in a limit so that the return type can't be inferred seems arbitrary. On Sun, Jan 15, 2017 at 12:41 AM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Fri Jan 13 2017, John McCall wrote: > > > I'm also

Re: [swift-evolution] Generic Subscripts

, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > > > Sent from my iPhone > > On Jan 11, 2017, at 11:05 PM, Chris Eidhof via swift-evolution < > swift-evolution@swift.org> wrote: > > Okay, > > I agree that throwing subscripts w

Re: [swift-evolution] Generic Subscripts

Okay, I agree that throwing subscripts would be great to have. Likewise, generic(and maybe even throwing) properties could be useful. However, I think that for this proposal, it makes more sense to focus on just generic subscripts, and mention throwing subscripts as "future improvements"? On

[swift-evolution] Generic Subscripts

Hi, Recently, I've bumped into the lack of generic subscripts a few times. There are a bunch of useful things you could do with it. It's in the generics manifesto as well: https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generic-subscripts I'm thinking of drafting up a

[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] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

(Sorry to be hijacking a different subthread, but I only just subscribed again to the mailing list) I understand why the proposal has its benefits. Yet, if we look at the SE-0009 rationale, we could apply much of that as an argument against this proposal, e.g. "anything that is widely repeated