>> 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
}
David.
>
>>
>> -Thorsten
>>
>>
>>> Am 03.05.2016 um 14:03 schrieb Matthew Johnson via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:
>>>
>>>
>>>
>>> Sent from my iPad
>>>
>>> On May 3, 2016, at 3:37 AM, Douglas Gregor via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>
>>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On May 2, 2016, at 3:50 PM, David Hart <da...@hartbit.com
>>>> <mailto:da...@hartbit.com>> 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 <dgre...@apple.com
>>>>>> <mailto:dgre...@apple.com>> wrote:
>>>>>>
>>>>>>
>>>>>>> On Apr 24, 2016, at 1:34 PM, David Hart via swift-evolution
>>>>>>> <swift-evolution@swift.org <mailto: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
>>>>>>> <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
>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <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
