Sent from my iPhone
> On May 2, 2016, at 3:50 PM, David Hart <[email protected]> wrote: > > 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? I think you need to clarify the intended name lookup semantics. Does name lookup for "AssocType" start its lookup in R or in Q? If the former, can one refer to an associated type newly defined in R? - Doug > > 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]> 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. >>> >> Believe it or not, I support this direction… >> >>> 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. >>> >> 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
