(I should mention that this is all just my personal read on the situation,
and shouldn't be construed as trying to stop or induce anyone else from
doing anything. Would love to see other proposals on generics, if people
want to work on them.)

On Tue, May 31, 2016 at 1:25 PM, Austin Zheng <austinzh...@gmail.com> 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).
>
> 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 <matt...@anandabits.com>
> wrote:
>
>>
>> On May 31, 2016, at 2:56 PM, Austin Zheng via swift-evolution <
>> swift-evolution@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 <clatt...@apple.com>
>> wrote:
>>
>>>
>>> On May 31, 2016, at 12:17 PM, L Mihalkovic via swift-evolution <
>>> swift-evolution@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 <austinzh...@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.mihalko...@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@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to