> Am 25.04.2016 um 15:40 schrieb Matthew Johnson via swift-evolution
> <swift-evolution@swift.org>:
>
> I really like this proposal. It is a nice step forward from current state.
>
> However, it looks like it doesn't allow us to express constraints that elate
> two or more associated types together, such as requiring both to have the
> same Element type.
Did I miss something? I thought that was the exact example given in the
motivation section?
-Thorsten
> I think it would be a good idea to solve the general problem of constraining
> associated types if possible. The general case is an important part of
> completing generics IMO so it should be within the scope of Swift 3 to
> consider it.
>
> Matthew
>
> Sent from my iPad
>
>> On Apr 24, 2016, at 3:34 PM, 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
>> Author(s): David Hart
>> Status: TBD
>> Review manager: TBD
>> 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
>> thread.
>>
>> 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
>> ...
>> }
>> 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.
>>
>> 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.
>> For those reasons, it might be wiser not to introduce the shorthand syntax.
>>
>> 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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
