> On Jan 3, 2016, at 9:14 PM, Drew Crawford <d...@sealedabstract.com> wrote:
>
> Sure, here's the start of the thread:
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001856.html
>
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001856.html>
Thanks. Joe was basically saying is that associated types would be
automatically bound to the existential for their constraints, or Any if there
are no constraints.
He didn’t specifically mention anything about Self, but I suppose Self
requirements could also be automatically bound to Any if the existential type
doesn’t specify anything more specific, although I’m not sure I would like that
behavior.
Self is what would apply in the case of:
> func compareTwo(first: Comparable, _ second: Comparable) -> Int { // error!
> if first < second {
> return -1
> }
> //...
> }
If Self were automatically bound to Any what would this do? Would it compile
and invoke a `<` operator that takes two Any parameters? That doesn’t seem to
make sense to me. It certainly wouldn’t guarantee you get the correct behavior
if first and second were both Int for example.
>
>
>> On Jan 3, 2016, at 9:10 PM, Matthew Johnson <matt...@anandabits.com
>> <mailto:matt...@anandabits.com>> wrote:
>>
>>
>>> On Jan 3, 2016, at 9:08 PM, Drew Crawford <d...@sealedabstract.com
>>> <mailto:d...@sealedabstract.com>> wrote:
>>>
>>>> Existentials for protocols with Self and / or associated type requirements
>>>> would require bindings for Self and / or the associated type(s). At least
>>>> when you use a member that contains Self and / or an associated type in
>>>> its signature. So the previous example will always fail to compile.
>>>
>>> Not true. Joe Groff:
>>
>> Can you point me to the source? I would like more context around these
>> comments.
>>
>>>
>>>> This seems like it would be addressed just by allowing Factory to be used
>>>> as a dynamic type, with its Product type generalized to Any. We'll be set
>>>> up to support that with some runtime work to store associated types in
>>>> protocol witness tables (which is also necessary to fix cyclic
>>>> conformances, one of our Swift 3 goals).
>>>
>>>
>>>> Yeah, when generalizing a protocol type, we ought to be able to either
>>>> generalize the associated types to their upper bounds, for use cases like
>>>> yours, or constrain them to specific types, for the AnyGenerator<T> kind
>>>> of case.
>>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
