[swift-evolution] Variadic generics discussion

[Austin Zheng]

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 <matthew at anandabits.com>
wrote:

>
> On May 31, 2016, at 2:56 PM, Austin Zheng via swift-evolution <
> swift-evolution at swift.org> 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 <clattner at apple.com>
> wrote:
>
>>
>> On May 31, 2016, at 12:17 PM, L Mihalkovic via swift-evolution <
>> swift-evolution at swift.org> 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 <austinzheng at gmail.com> 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 <
>> laurent.mihalkovic at gmail.com> 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
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160531/33b508bf/attachment.html>