Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

The “base” case desire makes sense to me, but not as a part of this proposal. It might be a good follow-on. If all associated values are enumerable, it is tempting to try to make the top level enum valueEnumerable too. I wonder if even that should be a follow-on feature. As far as

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

Has this stalled out again? I would like to help with the proposal and even attempt implementation. I also need to catch up on the resilient discussion regarding enum case ordering. > On Nov 14, 2017, at 10:50 PM, Jacob Bandes-Storch via swift-evolution > wrote:

Re: [swift-evolution] Revisiting SE-0132 Rationalizing Sequence end-operation names

I second Xiaodi. The new names are much improved. Land them in 4.1 or as soon as possible. Depreciations in 5 and removal in 6, though stability may not allow removal. > On Nov 2, 2017, at 9:58 PM, Xiaodi Wu via swift-evolution > wrote: > >> On Thu, Nov 2, 2017 at

Re: [swift-evolution] [Meta] WWDC week

I would love to meet up as well. Let's try to find a time and place. - Step > On May 31, 2017, at 2:11 PM, Alex Hoppen via swift-evolution > wrote: > > If there's something going on, I'll join as well. > If nobody has a location for a meetup, maybe we can just meet

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

Looks good. Minor comments below: > let t: P & C // Compiler error: subclass contraint must be in first position Typo: contraint should be constraint > ... > typealias TA4 = D & P2 > typealias TA5 = E & P2 > > typealias TA5 = TA1 & TA2 > typealias TA5 = class & P1 & class & P2 // Expansion >

Re: [swift-evolution] The lack of namespaces is leading people astray

I remain a fan of adding 'namespace' to the language. In the meantime I'll continue using the enum static member approach. But I would love to have something semantically cleaner. > El ene. 30, 2017, a las 3:09 PM, Robert Widmann via swift-evolution > escribió: >

[swift-evolution] Fwd: Reduce with inout

I like it. Inicio del mensaje reenviado: > De: Dave Abrahams via swift-evolution > Fecha: 16 de enero de 2017, 5:15:23 PM GMT+1 > Para: swift-evolution@swift.org > Asunto: Re: [swift-evolution] Reduce with inout > Responder a: Dave Abrahams > >

Re: [swift-evolution] Code comments that check code validity.

These (maintaining a clean codebase, using source control, branching) are good practices for solo developers as much as anyone else. > El ene. 15, 2017, a las 2:24 PM, Amir Michail via swift-evolution > escribió: > > >> On Jan 14, 2017, at 8:11 PM, Jay Abbott

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

Ah, thanks. No surprises there. I use a similar approach and it is often sufficient. `newtype` could reduce boilerplate there but not necessarily by a lot. Do you think that kind of "wrapper-type" replacement is the right place to target first? > El mar 20, 2016, a las 10:32 AM, Tino Heth