[swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

[Karl]

> On 22 Oct 2016, at 04:12, Karl <raziel.im+swift-evo at gmail.com> wrote:
> 
> 
>> On 22 Oct 2016, at 04:07, Karl <raziel.im+swift-evo at gmail.com <mailto:raziel.im+swift-evo at gmail.com>> wrote:
>> 
>> 
>>> On 22 Oct 2016, at 04:02, Braeden Profile <jhaezhyr12 at gmail.com <mailto:jhaezhyr12 at gmail.com>> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 (swift-evolution at swift.org <mailto:swift-evolution at swift.org>) 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
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161022/f59b3e8a/attachment.html>