> On Apr 12, 2016, at 11:23 PM, David Hart via swift-evolution
> <[email protected]> wrote:
>
> 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?
I think this is a fine feature to focus on. It’s useful, fits well in the
system, and it’s scope is small enough that it’s achievable.
- Doug
>
> David
>
> On 13 Apr 2016, at 01:46, Jacob Bandes-Storch via swift-evolution
> <[email protected] <mailto:[email protected]>> 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
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> on Tue Apr 12 2016, Douglas Gregor <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> > On Apr 11, 2016, at 1:01 AM, Jacob Bandes-Storch via swift-evolution
>> > <[email protected] <mailto:[email protected]>> 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
>> > <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
>> [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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
