> On 22 Oct 2016, at 04:12, Karl <[email protected]> wrote: > > >> On 22 Oct 2016, at 04:07, Karl <[email protected] >> <mailto:[email protected]>> wrote: >> >> >>> On 22 Oct 2016, at 04:02, Braeden Profile <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> But what would that mean? If I reference `ProtocolName.InnerType`, that >>> doesn’t always have meaning. In fact, if you have two different extensions >>> where AssociatedType equals something else, there’s a type ambiguity from >>> other code. I suspect it would only work if that InnerType was mandated to >>> be `private`. >> >> You would need a reference to a (ProtocolName where AssociatedType == Int), >> which you can get either from a `self` inside the extension or from a >> generic parameter: >> >> struct MyValue<T> : ProtocolName { typealias AssociatedType = T } >> >> let _ = MyValue<Int>().InnerType() > > No, wait - sorry, that’s wrong. I got confused for a second. You’re right; it > would have to be a private type.
Actually I think I take that back (I was just writing, lots of snippets floating around my head) - ProtocolName is a generic protocol, so types inside of it would become types on the concrete conformers. That’s consistent with the Editor.Delegate example in the draft proposal I linked to. So MyValue<Int>.InnerType would exist 👍 ProtocolName.InnerType isn’t really very meaningful otherwise. - Karl > >> >>> >>>> On Oct 17, 2016, at 12:44 PM, Adrian Zubarev via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> That option should not be disallowed. Here is a simple example you might >>>> want to build at some point: >>>> >>>> protocol ProtocolName { >>>> >>>> associatedtype AssociatedType >>>> } >>>> >>>> extension ProtocolName where AssociatedType == Int { >>>> >>>> struct InnerType {} >>>> } >>>> >>>> >>>> >>>> -- >>>> Adrian Zubarev >>>> Sent with Airmail >>>> >>>> Am 17. Oktober 2016 um 20:30:58, Karl via swift-evolution >>>> ([email protected] <mailto:[email protected]>) schrieb: >>>> >>>>> Is your vision that each conforming type would have to provide its own >>>>> nested type as specified by the protocol? >>>>> >>>>> Or could the protocol itself define a nested type and anything could use >>>>> it? >>>>> >>>>> protocol FloatingPoint: … { >>>>> enum RoundingRule { >>>>> // Do I put an implementation here? >>>>> } >>>>> } >>>>> >>>>> No, types which are defined inside the protocol are implemented there. >>>>> Providing your own types to satisfy a conformance is what associated >>>>> types are for. >>>>> >>>>> If you wanted something like that, you could do it with a nested protocol >>>>> + associated type: >>>>> >>>>> protocol FloatingPoint { >>>>> >>>>> protocol _RoundingRule { func round(_ : Super) -> Super } >>>>> associatedType RoundingRule : _RoundingRule >>>>> } >>>>> >>>>> struct Float : FloatingPoint { >>>>> >>>>> enum RoundingRule : _RoundingRule { >>>>> func round(_ val: Float) -> Float { >>>>> /* switch self, perform rounding… */ >>>>> } >>>>> } >>>>> } >>>>> >>>>> That brings up an interesting point, though - we would need a way to >>>>> refer to the outer protocol (I used “Super” here). >>>>> >>>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
