[swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Erica Sadun]

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 <swift-evolution at swift.org> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
> 
> Sent from my iPad
> 
> On Apr 28, 2016, at 5:49 PM, Erica Sadun <erica at ericasadun.com <>> wrote:
> 
>> 
>>> On Apr 28, 2016, at 12:18 PM, Matthew Johnson <matthew at anandabits.com <>> 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
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160428/88318c79/attachment.html>