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

> On Apr 12, 2016, at 11:23 PM, David Hart via swift-evolution > 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

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

> On Apr 12, 2016, at 11:19 PM, David Hart wrote: > > Hi Doug, > > I've read the discussion about moving the where clause to the right of > declarations (which I full-heartedly approve) but I don't see how it would > have any impact on the syntax of associated types

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

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

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

Hi Doug, I've read the discussion about moving the where clause to the right of declarations (which I full-heartedly approve) but I don't see how it would have any impact on the syntax of associated types requirements. David > On 12 Apr 2016, at 19:07, Douglas Gregor via swift-evolution >

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

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@swift.org> wrote: > > on Tue Apr 12 2016, Douglas Gregor

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

on Tue Apr 12 2016, Douglas Gregor wrote: > On Apr 11, 2016, at 1:01 AM, Jacob Bandes-Storch via swift-evolution > wrote: > > Doug wrote this in the Completing Generics manifesto, under "Minor > extensions": > >

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

> On Apr 11, 2016, at 1:01 AM, Jacob Bandes-Storch via swift-evolution > wrote: > > Doug wrote this in the Completing Generics manifesto, under "Minor > extensions": > > *Arbitrary requirements in protocols > > Currently, a new protocol can inherit from other

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

Hi Jacob, I really like the idea of constraining associated types. However I think there could be a much more general solution to this problem by introducing "Partially constrained protocols". I've already created a (almost finished) proposal for another thread which hasn't continued. It

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

on Mon Apr 11 2016, Jacob Bandes-Storch wrote: > On Mon, Apr 11, 2016 at 11:56 AM, Dave Abrahams via swift-evolution > wrote: > > on Mon Apr 11 2016, Jacob Bandes-Storch wrote: > > > Doug wrote this in the Completing Generics

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

On Mon, Apr 11, 2016 at 11:56 AM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Mon Apr 11 2016, Jacob Bandes-Storch wrote: > > > Doug wrote this in the Completing Generics manifesto, under "Minor > extensions": > > > > *Arbitrary

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

on Mon Apr 11 2016, Jacob Bandes-Storch 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 >

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

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