Right. If associated type has the same value for both conformances, then everything should be fine. Fixed that example.
- Anton 2016-06-13 0:15 GMT+03:00 Dan Appel <[email protected]>: > >if our protocol conforms to a protocol with associated type requirements, > then we still can't conform to our protocol multiple times. > > I don't think so: > > protocol A { > > associatedtype TypeA > > } > > > protocol B<TypeB>: A { > > func convert(from: TypeB) -> TypeA > > } > > > struct C: A { > > typealias TypeA = String > > } > > extension C: B<Int> { > > func convert(from int: Int) -> String { > > return String(int) > > } > > } > > extension C: B<Double> { > > func convert(from double: Double) -> String { > > return String(double) > > } > > } > > Seems to me like the above should work fine: the associated type is > declared once, but the generic protocol is conformed to multiple times. > > On Sun, Jun 12, 2016 at 1:22 PM Антон Жилин <[email protected]> > wrote: > >> Copy of link to the proposal: >> >> https://github.com/Anton3/swift-evolution/blob/generic-protocols/proposals/NNNN-generic-protocols.md >> >> Inline: >> >> 2016-06-12 21:51 GMT+03:00 Dan Appel <[email protected]>: >> >>> Awesome that you guys started this! I've been meaning to pitch it for a >>> while. Couple notes: >>> >>> - in the motivation, you're conforming to SequenceType while defining a >>> From protocol (just a typo I think) >>> >> >> Fixed >> >> >>> - the proposal should mention Brent's comments since it doesn't have a >>> rebuttal to the "unlikely" status generic protocols were given in the >>> generic manifesto. Brent does a great job of doing that >>> >> >> Added a bold link >> >> >>> - is there a way for generic protocols to still have associated types? I >>> think that could have some interesting use cases. >>> >> >> Generic protocols can contain associated types, but no type can conform >> to multiple instances of such protocols. >> >> Actually, this limitation is more restricting than it seems, because if >> our protocol conforms to a protocol with associated type requirements, then >> we still can't conform to our protocol multiple times. >> >> >>> Dan Appel >>> >>> On Sun, Jun 12, 2016 at 11:28 AM Антон Жилин <[email protected]> >>> wrote: >>> >> Yes, everything that works on generic types should work for generic >>>> protocols. I'll add that. >>>> >>>> What won't work is declaring that MyComparable : Comparable iff T == >>>> Self. The same won't work for current non-generic protocols as well. >>>> Although that feature is highly requested, it is discussed in a >>>> separate proposal. >>>> >>>> - Anton >>>> >>>> 2016-06-12 21:16 GMT+03:00 Xiaodi Wu <[email protected]>: >>>> >>>>> >>>>> >>>>> On Sun, Jun 12, 2016 at 8:01 AM, Антон Жилин < >>>>> [email protected]> wrote: >>>>> >>>>>> I've prepared a proper draft: >>>>>> >>>>>> >>>>>> https://github.com/Anton3/swift-evolution/blob/generic-protocols/proposals/NNNN-generic-protocols.md >>>>>> >>>>>> >>>>> When you propose this: >>>>> Syntax in protocol extensions >>>>> >>>>> protocol MyComparable<T> { >>>>> func < (left: Self, right: T) >>>>> }extension MyComparable { >>>>> func > (left: T, right: Self) { >>>>> return right < left >>>>> } >>>>> } >>>>> >>>>> >>>>> Would it be possible for me to write something like: >>>>> >>>>> ``` >>>>> extension MyComparable<T : SignedNumber> { ... } >>>>> ``` >>>>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>> -- >>> Dan Appel >>> >> -- > Dan Appel >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
