Hi Doug,
In the latest version of the proposal, which is now linked to a pull request, I
mentioned in the Detail Design section that the following syntax be valid:
protocol R : Q where AssocType : P {
// …
}
Can you read through that part of the proposal and let me know if it is
descriptive enough?
David.
> On 26 Apr 2016, at 05:28, Douglas Gregor <[email protected]> wrote:
>
>
>> On Apr 24, 2016, at 1:34 PM, David Hart via swift-evolution
>> <[email protected] <mailto:[email protected]>> 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.
>>
> Believe it or not, I support this direction…
>
>>
>> <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.
>>
> The only thing that bothers me about this syntax is that I have to introduce
> an associated type to add requirements. For example, what if I want my
> inheriting protocol to add a requirement to an existing associated type?
>
> protocol P { }
>
> protocol Q {
> typealias AssocType
> }
>
> protocol R : Q {
> // I want to just add “AssocType : P”, but I have to redeclare AssocType to
> do so
> typealias AssocType where AssocType : P
> }
>
> Did you consider an alternate syntax that puts the where clause outside the
> braces, e.g.,
>
> protocol R : Q where AssocType : P {
> // …
> }
>
> There are two things I like about this. First, it breaks the unnecessary link
> between an associated type and a (possibly unrelated) where clause,
> eliminating the need to redeclare associated types in inheriting protocols.
> Second, it’s effectively the same syntax as constrained extensions, which
> have a similar feel.
>
> Note that, if we do the above, I’d love to make it an error to define a new
> associated type with the same name as an associated type in an inherited
> protocol. It’s odd that we do so, and IIRC the only use case for it is to add
> requirement to an “existing” associated type.
>
> - Doug
>
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
