> Am 07.06.2016 um 07:55 schrieb LM <[email protected]>: > > > > On Jun 7, 2016, at 7:14 AM, Douglas Gregor <[email protected] > <mailto:[email protected]>> wrote: > >> >>> On Jun 6, 2016, at 10:08 PM, Thorsten Seitz <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> >>> Am 06.06.2016 um 22:13 schrieb L Mihalkovic <[email protected] >>> <mailto:[email protected]>>: >>> >>>> >>>>> On Jun 6, 2016, at 9:34 PM, Douglas Gregor <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> >>>>>> On Jun 6, 2016, at 12:12 PM, Thorsten Seitz <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> Am 06.06.2016 um 18:51 schrieb Douglas Gregor <[email protected] >>>>>> <mailto:[email protected]>>: >>>>>> >>>>>>> >>>>>>>> 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: >>>>>>> >>>>>>> 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? >>>>> >>>>> Yes, that’s correct. >>>>> >>>>>> 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? >>>>> >>>>> Effectively, yes: you can’t simply enumerate all of the cases because >>>>> some other module might add a new types/protocol extensions/conformances. >>>>> It has to be dynamically discoverable. >>>> >>>> yes… for each new module added to a known mix, the final conformances list >>>> can be completely different. >>> >>> But this is information known at compile time and does not have to be >>> determined at runtime. >>> An extension should be only effective in the module in which it is defined >>> and in modules using that module. All of these get to know the extension at >>> compile time. > > The idea of swift 3/4 is that the stdlib ABI should be stable enough that it > will be in the system rather than embedded in each app. Which means that the > conformance table must be runtime discoverable from the module exporting it > (in a section of the text segment), and its final effects computed by the > runtime when the module gets loaded (again coarse grained expl) by each > binary using it. This also lets them define new module boundaries in the > system that we can transitively inherit. > > Baking the final conformance statically into the module would leave us > wondering why our code might seem to be 'frozen' and not using newer system > defined conformances.
Good argument. So that would mean that the analysis would have to be done at linking time. This (like doing it at runtime) does open a can of worms about ambiguity, though: what happens when the new system version of a library suddenly defines an extension that conflicts with an extension in our module? Seems like that such a change should be confined to the system module unless doing a recompile, so we are back to my suggestion of resolving extensions at compile time? -Thorsten > Mind you... this may not be a stupid idea at all, as it might align better > with the practice of linking against specific SDKs to get a predictable level > of behavior. > > As for scope, my limited understanding of the loader is that there is no > 'source' field in these conformance records that would allow the runtime to > treat them hierarchically. > > >> >> That’s not the model that Swift uses today. You can discover protocol >> conformances introduce by modules—whether you knew about those modules at >> compile time (but at launch time you end up with newer versions) or whether >> those modules were unknown, you see the conformances. The standard library’s >> “print” facility depends on this behavior to find CustomStringConvertible >> conformances. >> >> Yes, we could make it all statically determined, but IMO that’s not the >> direction that Swift has been going. >> >> - Doug >> >>>> >>>>> >>>>> - Doug >>>>> >>>>>> >>>>>> -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] <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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
