Sent from my iPad
> On May 5, 2016, at 8:25 AM, David Hart <[email protected]> wrote: > >>> Answering Doug’s question: I’d like the name lookup to start in R and to be >>> able to refer to an associated type newly defined in R. >> >> This seems confusing to me. The associated type has not been introduced >> until inside the body of R. It doesn't make sense to allow them to be >> constrained prior to introduction and it offers no additional functionality. >> Separating the constraints on inherited associated types from the >> constraints on newly introduced associated types adds clarity and >> readability IMO. Lookup should only consider inherited protocols. > > I agree with you Matthew (as my proposal makes clear). If it started in R, > readers would have to scan both the declaration where clause and the > associated type where clause to get a full picture. > > protocol R : Q where AssocType.Generator.Element == Int { > associatedtype AssocType: Sequence > } > > vs > > protocol R : Q { > associatedtype AssocType: Sequence where AssocType.Generator.Element == > Int > } > Yep, I know you agree and am happy with the proposal. Just clarifying the rationale (as I see it) for Thorsten. > David. > >> >>> >>> -Thorsten >>> >>> >>>> Am 03.05.2016 um 14:03 schrieb Matthew Johnson via swift-evolution >>>> <[email protected]>: >>>> >>>> >>>> >>>> Sent from my iPad >>>> >>>>> On May 3, 2016, at 3:37 AM, Douglas Gregor via swift-evolution >>>>> <[email protected]> wrote: >>>>> >>>>> >>>>> >>>>> 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? >>>> >>>> To me this syntax reads as a constraint on Q only. If we need a >>>> constraint on associated types defined in R the constraint should be >>>> attached to the definition. >>>> >>>>> >>>>> - 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 >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
