Sent from my iPad

> On May 31, 2016, at 7:10 PM, Chris Lattner <[email protected]> wrote:
> 
> This is very close to my priority list.  That said, I think that all of these 
> are out of scope for swift 3 sadly.  

Happy to hear these priorities look about right to you also.  (I realized 
afterwards that I left off opening existentials which I would put around 5 or 6)

BTW, generalized existentials is #2 for me if we include things that already 
have proposals as well.  That going to be a game changer.

I've already been assuming we won't see any major new generics features in 
Swift 3.  

> 
> After Swift 3, the priority list will be driven by what the standard library 
> needs to get its APIs realized in their ideal form (eg without any of the _ 
> protocol hacks).  Conditional conformances certainly top the list, but we 
> will have to carefully and ruthlessly prioritize things in order to get to 
> ABI stability.

Makes sense.

> 
> -Chris
> 
>> On May 31, 2016, at 2: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

Reply via email to