> On Jun 5, 2016, at 3:24 AM, L. Mihalkovic via swift-evolution
> <[email protected]> wrote:
>
> The issue is to decide on the applicability scope. Thinking 'my app/their
> stuff' is an illusion. To the compiler & runtime there is only code split
> into modules, some in source code and others as dylibs (.dll, .so, ...). Any
> extension based conditional refines a protocol everywhere. What's hard is to
> compute the complete effects of these changes predictably, reliably and fast.
> Because when we consider 'but look, i have a single small extension', the
> compiler&runtime must be ready to deal symetrically with anything we throw at
> it. They can't start building 15 different ways the compute the side effects
> based on many different scenarios because it will be un-ruly code, and too
> complex to try to explain to us what we will see.
> The circular redefinitions case is one of the knightmares that hides in
> there... would mean having to assign priority to scopes, when there is no
> scopes yet. At the moment, the binary conformance table contains records for
> 3 types of conformances. First step would be to add a new type to match
> extension based conformance, and then record where it came from, and add some
> priority scheme to be able to navigate any conformance chain(remember that
> the pb grows everytime we decide 'oh cool, lets use a Padleft module rather
> than write my own 15 lines to do it - see the recent pb with nodejs). Not a
> simple task even with time, which they do not have now.
>
> @core_team i know this is a coarse explanation, but hopefully at least in the
> right ballpark.
Roughly, yes. The specific problem regards answering the question “where must
the runtime look to determine whether a given type X conforms to protocol P?”.
Right now, the runtime conceptually needs to look:
1) Into a list of known protocol conformances for the type X, and
2) If X is a class type, the list of known protocol conformances for
the superclass of X (recursively)
If we add the ability for a protocol extension to add a conformance to another
protocol, add to that:
3) Into the list of protocol extensions of other protocols Q that
provide conformance to P
That’s a fairly significant expansion, and for each of the protocol extensions
in (3), we need to evaluate whether X conforms to the extended protocol Q (and
any additional constraints placed on that protocol extension).
- Doug
>
> On Jun 5, 2016, at 9:49 AM, Thorsten Seitz via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
>
>>
>>> Am 04.06.2016 um 23:18 schrieb Austin Zheng via swift-evolution
>>> <[email protected] <mailto:[email protected]>>:
>>>
>>> Hello Dan,
>>>
>>> You'll be pleased to learn that conforming generic types conditionally to
>>> protocols is on the roadmap (and is one of the highest priority items for
>>> the versions of Swift following 3.0):
>>> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-
>>>
>>> <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances->
>>>
>>> However, it's unlikely that protocols will gain conditional conformance:
>>> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-via-protocol-extensions
>>>
>>> <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-via-protocol-extensions>
>> "However, similar to private conformances, it puts a major burden on the
>> dynamic-casting runtime to chase down arbitrarily long and potentially
>> cyclic chains of conformances, which makes efficient implementation nearly
>> impossible.“
>>
>> I’ve been wondering what the problem with the implementation is. I mean
>> instead of using an extension the same conformance could have been declared
>> beforehand, i.e. instead of
>>
>> protocol P { func foo() }
>> protocol Q { func bar() }
>> extension Q : P { func foo() { bar() } }
>>
>> we could have written the allowed
>>
>> protocol P { func foo() }
>> protocol Q : P { func foo() { bar() } }
>>
>> with the exact same effect.
>>
>> The only difference would be that the extension might have been in another
>> module than Q.
>> Is having to cross module boundaries causing the cited problems? Would the
>> same problems exist if in the second example Q would be defined in another
>> module?
>>
>> -Thorsten
>>
>>
>>>
>>> That document originates from a mailing list post made some time ago, and
>>> is a decent overview as to what sorts of type system features the Swift
>>> core developers are interested in building.
>>>
>>> Best,
>>> Austin
>>>
>>>> On Jun 4, 2016, at 2:12 PM, Dan Zimmerman via swift-evolution
>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>
>>>> Hey,
>>>>
>>>> I was interested in adopting the ability for a type that's generic in some
>>>> sense (either via generics or via associated types, in the case of
>>>> protocols) to conform to other protocols conditionally based on its type
>>>> parameter/associated type. For example:
>>>>
>>>> ```
>>>> extension CollectionType: Equatable where Generator.Element: Equatable {}
>>>>
>>>> func ==<Collection: CollectionType where Collection.Generator.Element:
>>>> Equatable>(left: Collection, right: Collection) -> Bool {
>>>> return zip(left, right).reduce(true) { accumulator, tuple in accumulator
>>>> && (tuple.0 == tuple.1) }
>>>> }
>>>> ```
>>>>
>>>> If this has already been proposed and knocked out/accepted please direct
>>>> me to the right place.
>>>> _______________________________________________
>>>> 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] <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] <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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
