Can you give me a specific example of where this approach fails for you? -- E
> On Apr 28, 2016, at 5:24 PM, Xiaodi Wu via swift-evolution > <[email protected]> wrote: > > I'm not sure that I'm entirely happy with this distinction between already > compiled types and ones that have not yet been compiled. It's a common Swift > idiom to implement protocol requirements in extensions, which encourages a > kind of modularity, if you will. Every so often (and maybe this isn't best > practice), I incorporate third-party code into a project in source form and > not as a compiled library (with attribution, and in compliance with the > license, etc., obviously). Often these are little snippets, perhaps useful > helper functions or types. The beauty of extensions is that I can extend > these as necessary without touching the original code. The point is, here one > would not be able to implement certain things in that way if this proposal is > adopted. To say that the workaround is just editing the original code is > deeply unsatisfying, because it would be equally valid to say that the same > workaround applies to stripping out extensions altogether for non-imported > types. > > > On Thu, Apr 28, 2016 at 6:09 PM, Howard Lovatt via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > It is a good idea to explicitly document the behaviour that this requirement > for override is a compile time check only and does not mean that already > compiled code has to be recompiled to allow a protocol to be retroactively > fitted to an already compiled type. > > > On Friday, 29 April 2016, Matthew Johnson via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > > > Sent from my iPad > > On Apr 28, 2016, at 5:49 PM, Erica Sadun <[email protected] <>> wrote: > >> >>> On Apr 28, 2016, at 12:18 PM, Matthew Johnson <[email protected] <>> >>> wrote: >>> We can't add the keywords if the structs are defined in a module we import >>> but don't own. We are only declaring the conformance retroactively. The >>> ability to do this is a crucial aspect of generic programming. It isn't >>> yet clear how your proposal handles retroactive modeling. >> >> These are compile-time checks and should not affect compiled code. > > Does that mean the conformance declaration will be accepted by the compiler > under your proposal? I would really like to see this called out explicitly > in the proposal. > >> >> -- E >> > > > -- > -- Howard. > > _______________________________________________ > 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
