I’m a strong +1 for this, although I’m suspicious of the timing as in my current project I could do with this right now ;)
> On 24 Apr 2016, at 21:34, David Hart via swift-evolution > <swift-evolution@swift.org> wrote: > > I wrote the proposal which was discussed to introduce generic constraints for > associated types. I’d like to get some feedback on it and get it ready before > submitting it: > > More Powerful Constraints for Associated Types > > Proposal: SE-XXXX > <https://github.com/hartbit/swift-evolution/blob/master/proposals/XXXX-powerful-constraints-associated-types.md> > Author(s): David Hart <http://github.com/hartbit> > Status: TBD > Review manager: TBD > > <https://github.com/hartbit/swift-evolution/blob/master/proposals/XXXX-powerful-constraints-associated-types.md#introduction>Introduction > > This proposal seeks to introduce a where expression to associated types > declarations to bring the same expressive power as generic type constraints. > > This proposal was discussed on the Swift Evolution list in the > [swift-evolution] [Completing Generics] Arbitrary requirements in protocols > <http://thread.gmane.org/gmane.comp.lang.swift.evolution/14243> thread. > > > <https://github.com/hartbit/swift-evolution/blob/master/proposals/XXXX-powerful-constraints-associated-types.md#motivation>Motivation > > Currently, associated type declarations can only express simple inheritance > constraints and not the more sophisticated constraints available to generic > types with the where expression. Some designs, including many in the Standard > Library, require more powerful constraints for associated types to be truly > elegant. For example, the SequenceType protocol can be declared as follows: > > protocol Sequence { > associatedtype Iterator : IteratorProtocol > associatedtype SubSequence : Sequence where SubSequence.Iterator.Element > == Iterator.Element > ... > } > > <https://github.com/hartbit/swift-evolution/blob/master/proposals/XXXX-powerful-constraints-associated-types.md#detail-design>Detail > Design > > With this proposal, the grammar for protocols associated types would be > modified to: > > protocol-associated-type-declaration → attributesopt access-level-modifieropt > associatedtype typealias-name type-inheritance-clauseopt > typealias-assignmentopt requirement-clauseopt > > The new requirement-clause is then used by the compiler to validate the > associated types of conforming types. > > > <https://github.com/hartbit/swift-evolution/blob/master/proposals/XXXX-powerful-constraints-associated-types.md#issues>Issues > > Douglas Gregor argues that the proposed syntax is redundant when adding new > constraints to an associated type declared in a parent protocol and proposes > another syntax: > > protocol Collection : Sequence { > where SubSequence : Collection > } > But as Douglas notes himself, that syntax will become ambiguous if we adopt > the generic where expression at the end of declarations like discussed in the > following thread: > http://thread.gmane.org/gmane.comp.lang.swift.evolution/13886/focus=14058 > <http://thread.gmane.org/gmane.comp.lang.swift.evolution/13886/focus=14058>. > For those reasons, it might be wiser not to introduce the shorthand syntax. > > > <https://github.com/hartbit/swift-evolution/blob/master/proposals/XXXX-powerful-constraints-associated-types.md#acknowledgements>Acknowledgements > > Thanks to Dave Abrahams and Douglas Gregor for taking the time to help me > through this proposal. > _______________________________________________ > 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
