[swift-evolution] [Draft Proposal] Require `final` on protocol extension members

[T.J. Usiyan]

I would rather see this go the 'other' way and allow us to mark methods as
final in the protocol declaration. There has been consistent talk of
letting the default implementation for protocol methods live inside of the
protocol and these two things together would be much better than this
proposal, in my opinion.  I agree that, as it is, marking protocol
extension methods as final would be helpful but I don't think that this is
the general way to go.

On Wed, Jan 6, 2016 at 8:20 PM, Howard Lovatt via swift-evolution <
swift-evolution at swift.org> wrote:

> The requirement for final for functions not from the protocol works well
> with a proposal in another thread for the requirement for override for
> functions that are from the protocol. Between the two proposals they allow
> the compiler to generate better error messages since the programmers
> intention is clear to the compiler (and to other humans).
>
>
> On Wednesday, 6 January 2016, Brent Royal-Gordon via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> > I think that it is a larger change, but if we’re going to change this,
>> shouldn’t we do it right?
>>
>> Okay, so let's sketch out a "doing it right" solution here. No
>> implementation details, just high-level ideas.
>>
>> If you want members added in extensions to be overridable, that basically
>> means you want them to add requirements to the protocol and then provide a
>> default implementation of those requirements. In other words, you're
>> reducing the distinction between the protocol and its extensions. This is a
>> goal of several other planned changes as well, such as letting you provide
>> default implementations directly in a protocol definition.
>>
>> I think it's fair to say that the ultimate goal here is to erase the
>> distinction between the protocol definition and its extensions as much as
>> possible. Now, it's probably not possible to make them completely
>> equivalent, because you can't allow an extension to break an existing
>> conformance. So, for instance, you probably can't put a requirement in an
>> extension unless you provide a default implementation. But this is not very
>> different from, for instance, not being able to declare stored properties
>> in concrete type extensions.
>>
>> So, if our ultimate goal is to, as much as possible, erase the
>> distinction between protocol declarations and protocol extensions, without
>> changing existing behavior, what are the changes needed? At a minimum, they
>> are:
>>
>> 1. Add `final` protocol members, and migrate current protocol extension
>> members to `final` members.
>> 2. Add an error when a `final` protocol member conflicts with a
>> conforming type's member.
>> 3. Permit default implementations in the main protocol definition.
>> 4. Permit protocol extensions to add conformances to other protocols
>> (with all the `where` clause bells and whistles).
>> 5. Allow protocol extensions to add requirements with default
>> implementations.
>>
>> I put them in this order because I think this is the order they should be
>> implemented in. 1 should come first because if it comes after 5, the exact
>> same source code can compile in two adjacent versions of Swift with
>> different semantics. I think we need to avoid this so that people can get
>> used to the new semantics. 2 needs to come early as well, both to justify
>> the use of `final` as the keyword, and to provide additional safety as the
>> definitions of protocols become more diffuse and fragmented. 3 and 4 I put
>> before 5 simply because I think they're most likely easier to implement.
>>
>> So in short, I think that even if you want to change protocol extensions
>> to add defaulted requirements, this proposal is a necessary first step. The
>> Swift development process encourages incremental development, with each
>> step in implementing a change refining the language in a useful way. I
>> think this is the step we should take right now. If it's the only change we
>> ever make in this direction, it will still be an improvement in the
>> language; if we take further steps, they will benefit from having this
>> change already implemented.
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
> --
>   -- 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/20160107/fe110b0f/attachment.html>