Hello Tony,
Sorry, I never took the time to comment. I see the issues you are pointing, but
they seem to be more generic than only concerning associated type constraints.
For example, the "inheritance from non-protocol, non-class type” error also
concerns generic types. Perhaps it should be best to start new discussions and
new proposal for those issues? This proposal already seems like a mouthful to
me.
David.
> On 25 Apr 2016, at 18:01, Tony Allevato via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> I really like where this proposal is headed.
>
> Would this syntax also support constraining associated types based on
> "inheritability" (for lack of a better word)? For example, a couple times
> I've hit a situation where I want to express a supertype/subtype
> relationship. A contrived example:
>
> protocol Foo {
> associatedtype Bar
>
> func f<Baz: Bar>(b: Baz.Type) -> Baz
> }
>
> This currently gives me the error "inheritance from non-protocol, non-class
> type 'Self.Bar'." This makes sense in a way, because a type conforming to Foo
> could define Bar to be anything, including a struct.
>
> I see a few ways to address this:
>
> (1) Allow users to write "associatedtype Bar: class" to indicate that the
> conforming class must set Bar to be a class type, which would let the type
> checker know that the Baz: Bar constraint is valid. This gets us partially
> there, but is still somewhat limiting because other supertype/subtype
> relationships could not be expressed, such as Bar being an arbitrary protocol
> and Baz being any type that conforms to that protocol.
>
> (2) Allow users to write "associatedtype Bar: _____", where _____ is some way
> of expressing any arbitrary type that is inheritable: this would include
> classes but also protocols. The difference here is instead of specifying a
> specific protocol, conforming types could put any protocol here, binding Bar
> in function f() to that protocol and then Baz would be any type conforming to
> Bar.
>
> (3) Allow the syntax above unchanged. If a conforming type defines Bar to be
> a struct, loosen the check and still allow it such that the only possible
> type that can satisfy Baz is Bar itself. This would be consistent with other
> generic constraints that are class-based, where a constraint of the form
> f<SomeClass: BaseClass> can still satisfy SomeClass by using BaseClass itself.
>
> While writing this, I noticed some other constructs that seem like they
> should work, but don't:
>
> protocol SomeProtocol {}
> protocol Foo {
> associatedtype Bar: SomeProtocol
> func f<Baz: Bar>(b: Baz.Type) -> Baz
> // ^ inheritance from non-protocol, non-class type 'Self.Bar'
> // Shouldn't the compiler know that Bar is constrained by a protocol here?
> }
>
> class SomeClass {}
> protocol Foo {
> associatedtype Bar: SomeClass
> func f<Baz: Bar>(b: Baz.Type) -> Baz
> // ^ inheritance from non-protocol, non-class type 'Self.Bar'
> // Same problem as above, essentially.
> }
>
> protocol A {}
> protocol B {}
> protocol Foo {
> associatedtype Bar: protocol<A, B>
> // ^ This one doesn't appear to even get past the parser, which is
> unfortunate.
> // To express the notion of an associatedtype conforming to two protocols,
> you
> // have to create a third protocol and extend the type you wish to use to
> conform
> // to that protocol.
> }
>
> Some of these issues may have been addressed in "Completing generics", but
> they seem like they would fit into this proposal as well.
>
> On Mon, Apr 25, 2016 at 8:30 AM Matthew Johnson via swift-evolution
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
>
> Sent from my iPad
>
> On Apr 25, 2016, at 9:58 AM, Thorsten Seitz <tseit...@icloud.com
> <mailto:tseit...@icloud.com>> wrote:
>
>>
>> Am 25.04.2016 um 15:40 schrieb Matthew Johnson via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:
>>
>>> I really like this proposal. It is a nice step forward from current state.
>>>
>>>
>>> However, it looks like it doesn't allow us to express constraints that
>>> elate two or more associated types together, such as requiring both to have
>>> the same Element type.
>>
>> Did I miss something? I thought that was the exact example given in the
>> motivation section?
>
> You are right. I'm not sure how I missed that. I think it is because the
> constraints are attached to a single associatedtype declaration rather than
> being at the top level of the protocol declaration.
>
> It feels slightly awkward to have to attach such constraints to one of the
> associatedtype declarations as they are effectively peers in the same type
> constraint. Allowing such constraints to stand alone would look similar to
> Doug's example in the issues section. I would prefer to look for a syntax
> for generic constraints on declarations that allows for freestanding and
> refined constraints in protocols.
>
>>
>> -Thorsten
>>
>>> I think it would be a good idea to solve the general problem of
>>> constraining associated types if possible. The general case is an
>>> important part of completing generics IMO so it should be within the scope
>>> of Swift 3 to consider it.
>>>
>>> Matthew
>>>
>>> Sent from my iPad
>>>
>>> On Apr 24, 2016, at 3: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.
>>>>
>>>>
>>>> <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.
>>>>
>>>>
>>>> <https://github.com/hartbit/swift-evolution/blob/master/proposals/XXXX-powerful-constraints-associated-types.md#issues>Issues
>>>>
>>>> Douglas Gregor argues that the proposed syntax is redundant when adding
>>>> new constraints to an associated type declared in a parent protocol and
>>>> proposes another syntax:
>>>>
>>>> protocol Collection : Sequence {
>>>> where SubSequence : Collection
>>>> }
>>>> But as Douglas notes himself, that syntax will become ambiguous if we
>>>> adopt the generic where expression at the end of declarations like
>>>> discussed in the following thread:
>>>> http://thread.gmane.org/gmane.comp.lang.swift.evolution/13886/focus=14058
>>>> <http://thread.gmane.org/gmane.comp.lang.swift.evolution/13886/focus=14058>.
>>>> For those reasons, it might be wiser not to introduce the shorthand
>>>> syntax.
>>>>
>>>>
>>>> <https://github.com/hartbit/swift-evolution/blob/master/proposals/XXXX-powerful-constraints-associated-types.md#acknowledgements>Acknowledgements
>>>>
>>>> Thanks to Dave Abrahams and Douglas Gregor for taking the time to help me
>>>> through this proposal.
>>>> _______________________________________________
>>>> 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 <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
