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

Xiaodi Wu xiaodi.wu at gmail.com
Thu Apr 28 18:24:37 CDT 2016

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> 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> 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
> 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/f40c5402/attachment.html>

More information about the swift-evolution mailing list