I have a proposal for #6 in the pipe, but there are actually some subtleties I have to work out (it's not as simple as just slapping a generic type signature on a let constant).
I think #5 is just considered a 'bug' and doesn't need a proposal (it might actually be finished already; I saw some commits recently); same with #4. #7 is not very useful without variadic generics (it pretty much exists to allow tuples to conform to protocols, and tuples are inherently variadic). I wanted to take a stab at #2. The core team has talked so much about #1 that I'd be surprised if they don't already have an idea as to how they want to do it, plus it's complicated for a number of reasons to get right. In such a case having the community push forward an alternate proposal would just be giving everyone more unneeded work. #3 seems semantically straightforward. AFAIK there's nothing a subscript can do that a getter and setter method can't do together, and methods can already be generic. A proposal shouldn't be hard to put together. Let me know your thoughts. Best, Austin On Tue, May 31, 2016 at 1:16 PM, Matthew Johnson <[email protected]> wrote: > > On May 31, 2016, at 2:56 PM, Austin Zheng via swift-evolution < > [email protected]> wrote: > > This is pretty much where my thinking about the topic has led me as well. > I'll resign this topic to pursue some other, hopefully more relevant work, > although anyone who wants to continue the discussion is welcome to. > > > Seems reasonable to wait until we can at least evaluate the macro approach > properly. > > Are you planning to continue work on generics? FWIW, my top priority list > for items without proposals is roughly: > > 1. Conditional conformance ( > https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances- > ) > 2. Parameterized extensions ( > https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#parameterized-extensions > ) > 3. Generic subscripts ( > https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generic-subscripts > ) > 4. Recursive protocol constraints ( > https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#nested-generics > ) > 5. Nested generics ( > https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#nested-generics > ) > 6. Default generic arguments ( > https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#default-generic-arguments > ) > 7. Extensions of structural types ( > https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types > ) > > And this one seems like low hanging fruit: > > Default implementations in protocols ( > https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#default-implementations-in-protocols- > ) > > How does this compare to your priorities for generics? > > > On Tue, May 31, 2016 at 12:49 PM, Chris Lattner <[email protected]> > wrote: > >> >> On May 31, 2016, at 12:17 PM, L Mihalkovic via swift-evolution < >> [email protected]> wrote: >> >> well there is no macro system, and for the moment a clear statement from >> chris that this is not on the table in the short term. the code in the >> example looked like run-of-the-mill swift, except for the “…". so that >> leaves us with swift looking code that would be executed by the compiler, >> but with nothing particular to tell which parts to and which not. just a >> thought. >> >> >> Lets be clear though: variadic generics are not in scope for Swift 3 >> either. >> >> I definitely don’t speak for the rest of the core team, nor have I >> discussed it with them… but IMO, this whole feature seems like a better >> fit for a macro system than it does to complicate the generics system. >> Unlike C++’s template system, our generics system inherently has runtime / >> dynamic dispatch properties, and I don’t think that shoehorning variadics >> into it is going to work out well. >> >> -Chris >> >> >> >> On May 31, 2016, at 7:59 PM, Austin Zheng <[email protected]> wrote: >> >> How so? I'm interested in anything that can get us away from having to >> generating code at compile-time. >> >> On Tue, May 31, 2016 at 10:04 AM, L. Mihalkovic < >> [email protected]> wrote: >> >>> >>> What's interesting about the code in the manifesto is that it looks very >>> much like "..." is a runtime construct, as opposed to trying the get the >>> compiler to do the heavy lifting. >>> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
