I’ve updated the proposal with comments from the discussions and opened a pull 
request. Please let me know if you have any feedback before it’s merged:

More Powerful Constraints for Associated Types

Proposal: SE-XXXX 
<https://github.com/apple/swift-evolution/blob/master/proposals/XXXX-associated-types-constraints.md>
Author(s): David Hart <http://github.com/hartbit>, Jacob Bandes-Storch 
<https://github.com/hartbit/swift-evolution/blob/associated-types-constraints/proposals/jtban...@gmail.com>,
 Douglas Gregor 
<https://github.com/hartbit/swift-evolution/blob/associated-types-constraints/proposals/dgre...@apple.com>
Status: TBD
Review manager: TBD
 
<https://github.com/hartbit/swift-evolution/blob/associated-types-constraints/proposals/XXXX-associated-types-constraints.md#introduction>Introduction

This proposal seeks to introduce a where clause to associated types 
declarations to bring the same expressive power as generic type constraints.

This proposal was discussed twice on the Swift Evolution list in the following 
threads:

[Completing Generics] Arbitrary requirements in protocols 
<http://thread.gmane.org/gmane.comp.lang.swift.evolution/14243>
More Powerful Constraints for Associated Types 
<http://thread.gmane.org/gmane.comp.lang.swift.evolution/15201>
 
<https://github.com/hartbit/swift-evolution/blob/associated-types-constraints/proposals/XXXX-associated-types-constraints.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 clause. 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/associated-types-constraints/proposals/XXXX-associated-types-constraints.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-clause­opt 
typealias-assignment­opt requirement-clauseopt

The new requirement-clause is then used by the compiler to validate the 
associated types of conforming types.

The proposal also allows protocols to use the associated types of their 
conforming protocols in their declaration where clause as below:

protocol IntSequence : Sequence where Iterator.Element == Int {
    ...
}
 
<https://github.com/hartbit/swift-evolution/blob/associated-types-constraints/proposals/XXXX-associated-types-constraints.md#alternatives>Alternatives

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 clause at the end of declarations like discussed in proposal 
SE-0081: Move where clause to end of declaration 
<https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md>.
 For those reasons, it might be wiser not to introduce the shorthand syntax.

 
<https://github.com/hartbit/swift-evolution/blob/associated-types-constraints/proposals/XXXX-associated-types-constraints.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

Reply via email to