> On 28 Feb 2017, at 22:45, Matthew Johnson via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>>
>> What is your evaluation of the proposal?
> +1, this is a fantastic proposal! I
>
> The proposal does not specifically call out whether a class may inherit from
> a subclass of a superclass constraint when a typealias is used in the
> inheritance list. I believe the following should be valid, but it would be a
> good idea to make that explicit:
>
> class B {}
> class D: B {}
> protocol P {}
> typealias BP = B & P
>
> class Foo: D, BP
It’s true that the proposal is not very clear about that specific scenario, but
I see it as valid. I touched about it in the “inheritance clauses and
typealias” section but only mentioned inheritance from the class in the
constraint. But rule 2 of the proposal kind of implies it: the first element in
the protocol composition syntax can be a class type to enforce the existential
to be a subtype of the class.
It would be worth being more precise about it, but not sure how a proposal can
be *fixed* during review.
>> Is the problem being addressed significant enough to warrant a change to
>> Swift?
> Yes, we are not able to correctly import class constrained protocols from
> Objective-C.
>
>> Does this proposal fit well with the feel and direction of Swift?
> Very much.
>
>> If you have used other languages or libraries with a similar feature, how do
>> you feel that this proposal compares to those?
> N/A
>
>> How much effort did you put into your review? A glance, a quick reading, or
>> an in-depth study?
> In-depth study of the original drafts. Quick read of the final review
> proposal.
> _______________________________________________
> 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
