Sent from my iPad
> On Apr 25, 2016, at 9:58 AM, Thorsten Seitz <tseit...@icloud.com> wrote:
>
>
>> 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?
You are right. I'm not sure how I missed that. I think it is because the
constraints are attached to a single associatedtype declaration rather than
being at the top level of the protocol declaration.
It feels slightly awkward to have to attach such constraints to one of the
associatedtype declarations as they are effectively peers in the same type
constraint. Allowing such constraints to stand alone would look similar to
Doug's example in the issues section. I would prefer to look for a syntax for
generic constraints on declarations that allows for freestanding and refined
constraints in protocols.
>
> -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
