> On Jun 6, 2016, at 12:37 PM, L Mihalkovic <[email protected]>
> wrote:
>
>>
>> On Jun 6, 2016, at 6:51 PM, Douglas Gregor <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>>
>>> On Jun 5, 2016, at 3:24 AM, L. Mihalkovic via swift-evolution
>>> <[email protected] <mailto:[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:
>
> I was under the impression that extension defined conformance would fit
> neither NormalProtocolConformance (nominal) nor
> SpecializedProtocolConformance (generic) and that a
> StrawmanExtensionProtocolConformance would then be required.
Well, that’s an implementation detail of the AST itself. We’d probably be able
to leverage NormalProtocolConformance for this.
>
>>
>> 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).
>
> because of the potential for contradictory definitions or redefinitions, I
> was under the impression that it might be useful to define some sort of
> prioritization for deciding which should be applied first. But that’s
> probably because I don’t understand the topic as much as you do. That is also
> why I was thinking that aside from priority, the structures might also have
> to be tagged with something to tell where they come from (maybe priority is
> just how these scope source are read). I guess this is also a requirement
> that would stem from supporting private/local conformance.
Yes, if we admit multiple conformances of the same type X to a protocol P, we
need some way to resolve the ambiguity *at runtime*. That has a cost, which
could be significant depending on the chosen scheme. Personally, I don’t think
we ever want to admit multiple/private/local conformances.
- Doug
>
>> - 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] <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
