To me it reads as a constraint on R. Otherwise we would have to write `protocol
R where … : Q where …, S where … { … }` which would not only be confusing but
would not make much sense IMHO because I want to be able to write constraints
which combine associated types from R, Q and S, i.e. from all sources
contributing to R.
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.
-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] <mailto:[email protected]>> wrote:
>
>>
>>
>> Sent from my iPhone
>>
>> On May 2, 2016, at 3:50 PM, David Hart <[email protected]
>> <mailto:[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]
>>>> <mailto:[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] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <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
