[swift-evolution] [Completing Generics] Arbitrary requirements in protocols

[David Hart]

I wouldn't mind driving the discussion and proposal, because I'd really like to see a more complete generics system. Before I start, can David or Doug, or someone else with a high-level view of the generics system tell me if this is where to start or if there is another feature in the Complete Generics manifesto which is more urgent first?

David

> On 13 Apr 2016, at 01:46, Jacob Bandes-Storch via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I'm interested, but I'm by no means claiming I'll have enough time to drive any of the discussion/proposal/implementation. :-(
> 
> Jacob
> 
>> On Tue, Apr 12, 2016 at 3:07 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> on Tue Apr 12 2016, Douglas Gregor <swift-evolution at swift.org> wrote:
>> 
>> >     On Apr 11, 2016, at 1:01 AM, Jacob Bandes-Storch via swift-evolution
>> >     <swift-evolution at swift.org> wrote:
>> >
>> >     Doug wrote this in the Completing Generics manifesto, under "Minor
>> >     extensions":
>> >
>> >         *Arbitrary requirements in protocols
>> >
>> >         Currently, a new protocol can inherit from other protocols, introduce
>> >         new associated types, and add new conformance constraints to associated
>> >         types (by redeclaring an associated type from an inherited protocol).
>> >         However, one cannot express more general constraints. Building on the
>> >         example from “Recursive protocol constraints”, we really want the
>> >         element type of a Sequence’s SubSequence to be the same as the element
>> >         type of the Sequence, e.g.,
>> >
>> >         protocol Sequence {
>> >         associatedtype Iterator : IteratorProtocol
>> >         …
>> >         associatedtype SubSequence : Sequence where SubSequence.Iterator.Element
>> >         == Iterator.Element
>> >         }
>> >
>> >     +1.
>> >
>> >     To make it into Swift 3, would this feature require a proposal of its own?
>> >
>> > Yes. Also, be wary that the syntax above potentially conflicts with the syntax
>> > discussed as "moving the where clauses”:
>> >
>> > http://thread.gmane.org/gmane.comp.lang.swift.evolution/13886/focus=14058
>> >
>> >     How feasible would it be to implement on top of the current system?
>> >
>> > Definitely! The archetype builder would need to learn to check these extra where
>> > clauses, and one would need to be sure that the constraint solver is picking
>> > them up as well.
>> 
>> By the way, having this would enable us to massively simplify the
>> standard library, and potentially lots of user-written generic code,
>> too.  So I'm very excited that someone's interested!
>> 
>> --
>> Dave
>> 
>> _______________________________________________
>> 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/20160413/5eeb649b/attachment.html>