> Am 06.06.2016 um 18:51 schrieb Douglas Gregor <[email protected]>:
>
>
>> 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
So, the difference is that in the case
protocol P { ... }
protocol Q : P { ... }
struct X : Q {...}
X's list of known protocol conformances already contains Q and P,
whereas in the case
protocol P { ... }
protocol Q { ... }
struct X : Q {...}
extension Q : P
X's list of known protocol conformances just contains Q and is not extended by
P as a result of the extension?
Did I understand this right? Is that (not being able to extend the conformance
lists of all types as a result of an extension) a restriction of having module
boundaries? Or is it simply not feasible for other reasons?
-Thorsten
>
> 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]> wrote:
>>
>>>
>>>> Am 04.06.2016 um 23:18 schrieb Austin Zheng via swift-evolution
>>>> <[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-
>>>>
>>>> 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
>>>
>>> "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]> 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]
>>>>> 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
>> _______________________________________________
>> 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
