> On May 31, 2016, at 3:25 PM, Austin Zheng <[email protected]> wrote: > > 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).
Cool. Looking forward to reviewing a draft when it’s ready. > > 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). > Good to know 4 and 5 are considered bugs. I know #4 is important for the standard library so I suppose that will ensure it is a priority soon enough. I included #7 because it would still be nice to have for a number of reasons. Maybe there is a way to pull it off for a handful of types that are known to the compiler. > I wanted to take a stab at #2. Are you still thinking about this one or did you decide not to pursue it? > 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. Agree here as well. I’ve avoided generics proposals mostly because I thought the core team was leading the charge on all them. It now appears like that may not have been the right assumption across the board. I wish we had a bit more visibility on this... > > #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. Agree. Someone just needs to jump in and write it up. :-) If it had a chance of making it into Swift 3 I would do it right away, but it’s hard to tell... > > Let me know your thoughts. > > Best, > Austin > > > > > On Tue, May 31, 2016 at 1:16 PM, Matthew Johnson <[email protected] > <mailto:[email protected]>> wrote: > >> On May 31, 2016, at 2:56 PM, Austin Zheng via swift-evolution >> <[email protected] <mailto:[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- > > <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 > > <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 > > <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 > > <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 > > <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 > > <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 > > <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- > > <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] >> <mailto:[email protected]>> wrote: >> >>> On May 31, 2016, at 12:17 PM, L Mihalkovic via swift-evolution >>> <[email protected] <mailto:[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] >>>> <mailto:[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] <mailto:[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] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
