I had a go at writing this up formally: https://gist.github.com/karwa/4c6bff75f8fa84b16df2c8caae97d622 <https://gist.github.com/karwa/4c6bff75f8fa84b16df2c8caae97d622>
Is there anything I missed? - Karl > On 17 Oct 2016, at 20:44, Adrian Zubarev <[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] https://lists.swift.org/mailman/listinfo/swift-evolution
