Sent from my iPad
> On May 3, 2016, at 3:37 AM, Douglas Gregor via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>
> Sent from my iPhone
>
>> On May 2, 2016, at 3:50 PM, David Hart <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> wrote:
>>>>
>>>>
>>>> On Apr 24, 2016, at 1:34 PM, David Hart via swift-evolution
>>>> <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
>>>> 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
> 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
