[Draft] Remove support for final in protocol extensions

Hey Folks, This draft proposal addresses starter bug SR-1762. I believe
this is in scope for Swift 4 since it impacts source compatibility. It's
not a very exciting proposal, but I think it will help make Swift a little
more consistent.

https://bugs.swift.org/browse/SR-1762

Thanks

Brian
Introduction

This proposal suggests removing support for the final keyword when
declaring a function in a protocol extension. The presence of the final keyword
does not currently generate an error message, and it does not actually
modify the dispatch behavior in any way.
<Remove support for final in protocol extensions · GitHub;
Motivation

In the original protocol model of Swift, a developer could use the
final keyword
when declaring a function in a protocol extension to ensure the function
could not be overridden. This keyword has no use in Swift's current
protocol model, since functions in protocol extensions can not be
overridden and will always use direct dispatch.
<Remove support for final in protocol extensions · GitHub
design

The compiler should generate an error or warning when the final keyword is
used on a function declaration inside of a protocol extension. This is
consistent with the use of final in structs and enumerations.
<Remove support for final in protocol extensions · GitHub
compatibility

This change will impact source compatibility. To maintain compatibility
with Swift 3, a warning will be generated in Swift 3 mode instead of an
error message.
<Remove support for final in protocol extensions · GitHub
on ABI stability

This has no effect on ABI stability
<Remove support for final in protocol extensions · GitHub
on API resilience

This has no effect on API resilience
<Remove support for final in protocol extensions · GitHub
considered

The only alternative would be to not fix this bug

It makes sense since protocol do not allow final. It doesn't make much
sense to allow the extensions to be exempt from this.

Classes that inherit from it can still provide their own implementation of
the supposed "final" protocol method which is contradictory to what final
means.

Protocol extensions should not allow final since the protocol definition
doesn't allow it either.

···

On Tue, Mar 7, 2017 at 10:23 PM Brian King via swift-evolution < swift-evolution@swift.org> wrote:

Hey Folks, This draft proposal addresses starter bug SR-1762. I believe
this is in scope for Swift 4 since it impacts source compatibility. It's
not a very exciting proposal, but I think it will help make Swift a little
more consistent.

Remove support for final in protocol extensions · GitHub
[SR-1762] Using "final" keyword in protocol extension doesn't prevent overriding · Issue #44371 · apple/swift · GitHub

Thanks

Brian
Introduction

This proposal suggests removing support for the final keyword when
declaring a function in a protocol extension. The presence of the final keyword
does not currently generate an error message, and it does not actually
modify the dispatch behavior in any way.

<Remove support for final in protocol extensions · GitHub;
Motivation

In the original protocol model of Swift, a developer could use the final keyword
when declaring a function in a protocol extension to ensure the function
could not be overridden. This keyword has no use in Swift's current
protocol model, since functions in protocol extensions can not be
overridden and will always use direct dispatch.

<Remove support for final in protocol extensions · GitHub
design

The compiler should generate an error or warning when the final keyword
is used on a function declaration inside of a protocol extension. This is
consistent with the use of final in structs and enumerations.

<Remove support for final in protocol extensions · GitHub
compatibility

This change will impact source compatibility. To maintain compatibility
with Swift 3, a warning will be generated in Swift 3 mode instead of an
error message.

<Remove support for final in protocol extensions · GitHub
on ABI stability

This has no effect on ABI stability

<Remove support for final in protocol extensions · GitHub
on API resilience

This has no effect on API resilience

<Remove support for final in protocol extensions · GitHub
considered

The only alternative would be to not fix this bug
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I think the fact that the type checker permits ‘final’ to appear inside protocol extensions is an oversight and this probably does not even warrant a proposal. I don’t think allowing this was ever part of the conceptual model of protocol extensions at any point in time (if you recall they were introduced ‘recently’, in Swift 2). If someone put together a PR which makes ‘final’ in protocol extensions an error in Swift 4 mode (and a warning in 3), I would merge it.

FWIW that there is one restriction around the direct dispatch here we want to lift, but it’s not related to this proposal.

If you have a base class conforming to a protocol using default requirements, eg

  protocol Proto { func f() }
  extension Proto { func f() { } }

  class Base : Proto {}

Currently the witness table for Base : Proto directly references the extension method Proto.f.

We want to allow this, at least inside the module:

class Derived {
  override func f() {} // does not work currently
}

This will mean that ‘Proto.f’ will appear in the vtable of ‘Base’, pointing at the extension method. The conformance will dispatch through the vtable instead of directly calling the extension method.

Slava

···

On Mar 7, 2017, at 7:23 PM, Brian King via swift-evolution <swift-evolution@swift.org> wrote:

Hey Folks, This draft proposal addresses starter bug SR-1762. I believe this is in scope for Swift 4 since it impacts source compatibility. It's not a very exciting proposal, but I think it will help make Swift a little more consistent.

Remove support for final in protocol extensions · GitHub
[SR-1762] Using "final" keyword in protocol extension doesn't prevent overriding · Issue #44371 · apple/swift · GitHub

Thanks

Brian
Introduction

This proposal suggests removing support for the final keyword when declaring a function in a protocol extension. The presence of the final keyword does not currently generate an error message, and it does not actually modify the dispatch behavior in any way.

<Remove support for final in protocol extensions · GitHub

In the original protocol model of Swift, a developer could use the final keyword when declaring a function in a protocol extension to ensure the function could not be overridden. This keyword has no use in Swift's current protocol model, since functions in protocol extensions can not be overridden and will always use direct dispatch.

<Remove support for final in protocol extensions · GitHub design

The compiler should generate an error or warning when the final keyword is used on a function declaration inside of a protocol extension. This is consistent with the use of final in structs and enumerations.

<Remove support for final in protocol extensions · GitHub compatibility

This change will impact source compatibility. To maintain compatibility with Swift 3, a warning will be generated in Swift 3 mode instead of an error message.

<Remove support for final in protocol extensions · GitHub on ABI stability

This has no effect on ABI stability

<Remove support for final in protocol extensions · GitHub on API resilience

This has no effect on API resilience

<Remove support for final in protocol extensions · GitHub considered

The only alternative would be to not fix this bug

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I think the fact that the type checker permits ‘final’ to appear inside protocol extensions is an oversight and this probably does not even warrant a proposal. I don’t think allowing this was ever part of the conceptual model of protocol extensions at any point in time (if you recall they were introduced ‘recently’, in Swift 2). If someone put together a PR which makes ‘final’ in protocol extensions an error in Swift 4 mode (and a warning in 3), I would merge it.

FWIW that there is one restriction around the direct dispatch here we want to lift, but it’s not related to this proposal.

If you have a base class conforming to a protocol using default requirements, eg

  protocol Proto { func f() }
  extension Proto { func f() { } }

  class Base : Proto {}

Currently the witness table for Base : Proto directly references the extension method Proto.f.

We want to allow this, at least inside the module:

class Derived {
  override func f() {} // does not work currently
}

This will mean that ‘Proto.f’ will appear in the vtable of ‘Base’, pointing at the extension method. The conformance will dispatch through the vtable instead of directly calling the extension method.

Would this allow the override to call `Proto.f` through super?

···

Sent from my iPad

On Mar 9, 2017, at 2:23 AM, Slava Pestov via swift-evolution <swift-evolution@swift.org> wrote:

Slava

On Mar 7, 2017, at 7:23 PM, Brian King via swift-evolution <swift-evolution@swift.org> wrote:

Hey Folks, This draft proposal addresses starter bug SR-1762. I believe this is in scope for Swift 4 since it impacts source compatibility. It's not a very exciting proposal, but I think it will help make Swift a little more consistent.

Remove support for final in protocol extensions · GitHub
[SR-1762] Using "final" keyword in protocol extension doesn't prevent overriding · Issue #44371 · apple/swift · GitHub

Thanks

Brian
Introduction

This proposal suggests removing support for the final keyword when declaring a function in a protocol extension. The presence of the final keyword does not currently generate an error message, and it does not actually modify the dispatch behavior in any way.

Motivation

In the original protocol model of Swift, a developer could use the final keyword when declaring a function in a protocol extension to ensure the function could not be overridden. This keyword has no use in Swift's current protocol model, since functions in protocol extensions can not be overridden and will always use direct dispatch.

Detailed design

The compiler should generate an error or warning when the final keyword is used on a function declaration inside of a protocol extension. This is consistent with the use of final in structs and enumerations.

Source compatibility

This change will impact source compatibility. To maintain compatibility with Swift 3, a warning will be generated in Swift 3 mode instead of an error message.

Effect on ABI stability

This has no effect on ABI stability

Effect on API resilience

This has no effect on API resilience

Alternatives considered

The only alternative would be to not fix this bug

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I have a change ready and can turn it into a PR. Jordan mentioned in the
bug that this would require a SE proposal, but looking at this as a bug in
the current implementation rather than a change in the language makes
sense. It certainly is trivial enough, and doesn't change any semantics, so
I'll make a PR today.

If we do want a proposal to move forward Erica gave me some great language
updates that I can address.

The other bug [SR-103] Protocol Extension: function's implementation cannot be overridden by a subclass · Issue #42725 · apple/swift · GitHub looks like it's been
getting some attention and debate on if it should go through the evolution
process.

Brian

···

On Thu, Mar 9, 2017 at 3:23 AM, Slava Pestov <spestov@apple.com> wrote:

I think the fact that the type checker permits ‘final’ to appear inside
protocol extensions is an oversight and this probably does not even warrant
a proposal. I don’t think allowing this was ever part of the conceptual
model of protocol extensions at any point in time (if you recall they were
introduced ‘recently’, in Swift 2). If someone put together a PR which
makes ‘final’ in protocol extensions an error in Swift 4 mode (and a
warning in 3), I would merge it.

FWIW that there is one restriction around the direct dispatch here we want
to lift, but it’s not related to this proposal.

If you have a base class conforming to a protocol using default
requirements, eg

  protocol Proto { func f() }
  extension Proto { func f() { } }

  class Base : Proto {}

Currently the witness table for Base : Proto directly references the
extension method Proto.f.

We want to allow this, at least inside the module:

class Derived {
  override func f() {} // does not work currently
}

This will mean that ‘Proto.f’ will appear in the vtable of ‘Base’,
pointing at the extension method. The conformance will dispatch through the
vtable instead of directly calling the extension method.

Slava

On Mar 7, 2017, at 7:23 PM, Brian King via swift-evolution < > swift-evolution@swift.org> wrote:

Hey Folks, This draft proposal addresses starter bug SR-1762. I believe
this is in scope for Swift 4 since it impacts source compatibility. It's
not a very exciting proposal, but I think it will help make Swift a little
more consistent.

Remove support for final in protocol extensions · GitHub
[SR-1762] Using "final" keyword in protocol extension doesn't prevent overriding · Issue #44371 · apple/swift · GitHub

Thanks

Brian
Introduction

This proposal suggests removing support for the final keyword when
declaring a function in a protocol extension. The presence of the final keyword
does not currently generate an error message, and it does not actually
modify the dispatch behavior in any way.

<Remove support for final in protocol extensions · GitHub;
Motivation

In the original protocol model of Swift, a developer could use the final keyword
when declaring a function in a protocol extension to ensure the function
could not be overridden. This keyword has no use in Swift's current
protocol model, since functions in protocol extensions can not be
overridden and will always use direct dispatch.

<Remove support for final in protocol extensions · GitHub
design

The compiler should generate an error or warning when the final keyword
is used on a function declaration inside of a protocol extension. This is
consistent with the use of final in structs and enumerations.

<Remove support for final in protocol extensions · GitHub
compatibility

This change will impact source compatibility. To maintain compatibility
with Swift 3, a warning will be generated in Swift 3 mode instead of an
error message.

<Remove support for final in protocol extensions · GitHub
on ABI stability

This has no effect on ABI stability

<Remove support for final in protocol extensions · GitHub
on API resilience

This has no effect on API resilience

<Remove support for final in protocol extensions · GitHub
considered
The only alternative would be to not fix this bug
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

My question is why cannot the Base type override the default implementation? I might want to override it, by calling the default implementation and modifying the result for my needs.

Something like that:

protocol P {
    func foo() -> Int
}

extension P {
    func foo() -> Int {
        return 42
    }
}

class Base : P {
    override func foo() -> {
         
        return default.foo() * 100
    }
}
The example is kept simple.

···

--
Adrian Zubarev
Sent with Airmail

Am 9. März 2017 um 14:37:08, Matthew Johnson via swift-evolution (swift-evolution@swift.org) schrieb:

Sent from my iPad

On Mar 9, 2017, at 2:23 AM, Slava Pestov via swift-evolution <swift-evolution@swift.org> wrote:

I think the fact that the type checker permits ‘final’ to appear inside protocol extensions is an oversight and this probably does not even warrant a proposal. I don’t think allowing this was ever part of the conceptual model of protocol extensions at any point in time (if you recall they were introduced ‘recently’, in Swift 2). If someone put together a PR which makes ‘final’ in protocol extensions an error in Swift 4 mode (and a warning in 3), I would merge it.

FWIW that there is one restriction around the direct dispatch here we want to lift, but it’s not related to this proposal.

If you have a base class conforming to a protocol using default requirements, eg

protocol Proto { func f() }
extension Proto { func f() { } }

class Base : Proto {}

Currently the witness table for Base : Proto directly references the extension method Proto.f.

We want to allow this, at least inside the module:

class Derived {
override func f() {} // does not work currently
}

This will mean that ‘Proto.f’ will appear in the vtable of ‘Base’, pointing at the extension method. The conformance will dispatch through the vtable instead of directly calling the extension method.

Would this allow the override to call `Proto.f` through super?

Slava

On Mar 7, 2017, at 7:23 PM, Brian King via swift-evolution <swift-evolution@swift.org> wrote:

Hey Folks, This draft proposal addresses starter bug SR-1762. I believe this is in scope for Swift 4 since it impacts source compatibility. It's not a very exciting proposal, but I think it will help make Swift a little more consistent.

https://bugs.swift.org/browse/SR-1762

Thanks

Brian
Introduction

This proposal suggests removing support for the final keyword when declaring a function in a protocol extension. The presence of the final keyword does not currently generate an error message, and it does not actually modify the dispatch behavior in any way.

Motivation

In the original protocol model of Swift, a developer could use the final keyword when declaring a function in a protocol extension to ensure the function could not be overridden. This keyword has no use in Swift's current protocol model, since functions in protocol extensions can not be overridden and will always use direct dispatch.

Detailed design

The compiler should generate an error or warning when the final keyword is used on a function declaration inside of a protocol extension. This is consistent with the use of final in structs and enumerations.

Source compatibility

This change will impact source compatibility. To maintain compatibility with Swift 3, a warning will be generated in Swift 3 mode instead of an error message.

Effect on ABI stability

This has no effect on ABI stability

Effect on API resilience

This has no effect on API resilience

Alternatives considered

The only alternative would be to not fix this bug

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

There has been a lot of discussion around this design decision. Personally, I’m with you: this should be allowed. Protocol extensions should be defaults, nothing more.

The rationale mentioned in Swift Evolution for discouraging this behaviour tends to be that if you conform to the protocol, you should conform and adhere to all its extensions as well, and that not doing so in the same way will be inconsistent.

I personally think this comes to the Type-first vs Protocol-first approach and I think instances of types should have the final say in the behaviour of the operation. While this would perform slightly worse, and could potentially be unsafe, I think it is consistent with the fact that not all implementers of a protocol behave exactly the same; indeed, if they did, we’d only have one type per protocol, in which case, what is the point of a protocol at all? Just do it with types.

I love POP and protocol extensions but I’m tempered by the fact that not all types implement protocols in the same ways, and we can’t predict ahead of time where those differences will be needed.

···

On 10 Mar 2017, at 12:48 am, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

My question is why cannot the Base type override the default implementation? I might want to override it, by calling the default implementation and modifying the result for my needs.

Something like that:

protocol P {
    func foo() -> Int
}

extension P {
    func foo() -> Int {
        return 42
    }
}

class Base : P {
    override func foo() -> {
         
        return default.foo() * 100
    }
}
The example is kept simple.

--
Adrian Zubarev
Sent with Airmail

Am 9. März 2017 um 14:37:08, Matthew Johnson via swift-evolution (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

Sent from my iPad

On Mar 9, 2017, at 2:23 AM, Slava Pestov via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I think the fact that the type checker permits ‘final’ to appear inside protocol extensions is an oversight and this probably does not even warrant a proposal. I don’t think allowing this was ever part of the conceptual model of protocol extensions at any point in time (if you recall they were introduced ‘recently’, in Swift 2). If someone put together a PR which makes ‘final’ in protocol extensions an error in Swift 4 mode (and a warning in 3), I would merge it.

FWIW that there is one restriction around the direct dispatch here we want to lift, but it’s not related to this proposal.

If you have a base class conforming to a protocol using default requirements, eg

  protocol Proto { func f() }
  extension Proto { func f() { } }

  class Base : Proto {}

Currently the witness table for Base : Proto directly references the extension method Proto.f.

We want to allow this, at least inside the module:

class Derived {
  override func f() {} // does not work currently
}

This will mean that ‘Proto.f’ will appear in the vtable of ‘Base’, pointing at the extension method. The conformance will dispatch through the vtable instead of directly calling the extension method.

Would this allow the override to call `Proto.f` through super?

Slava

On Mar 7, 2017, at 7:23 PM, Brian King via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hey Folks, This draft proposal addresses starter bug SR-1762. I believe this is in scope for Swift 4 since it impacts source compatibility. It's not a very exciting proposal, but I think it will help make Swift a little more consistent.

Remove support for final in protocol extensions · GitHub
[SR-1762] Using "final" keyword in protocol extension doesn't prevent overriding · Issue #44371 · apple/swift · GitHub

Thanks

Brian
Introduction

This proposal suggests removing support for the final keyword when declaring a function in a protocol extension. The presence of the final keyword does not currently generate an error message, and it does not actually modify the dispatch behavior in any way.

<Remove support for final in protocol extensions · GitHub

In the original protocol model of Swift, a developer could use the final keyword when declaring a function in a protocol extension to ensure the function could not be overridden. This keyword has no use in Swift's current protocol model, since functions in protocol extensions can not be overridden and will always use direct dispatch.

<Remove support for final in protocol extensions · GitHub design

The compiler should generate an error or warning when the final keyword is used on a function declaration inside of a protocol extension. This is consistent with the use of final in structs and enumerations.

<Remove support for final in protocol extensions · GitHub compatibility

This change will impact source compatibility. To maintain compatibility with Swift 3, a warning will be generated in Swift 3 mode instead of an error message.

<Remove support for final in protocol extensions · GitHub on ABI stability

This has no effect on ABI stability

<Remove support for final in protocol extensions · GitHub on API resilience

This has no effect on API resilience

<Remove support for final in protocol extensions · GitHub considered

The only alternative would be to not fix this bug

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

+1 for the fix. Solid and straightforward.

···

On Thu, Mar 9, 2017 at 9:32 AM, Rod Brown via swift-evolution < swift-evolution@swift.org> wrote:

There has been a lot of discussion around this design decision.
Personally, I’m with you: this should be allowed. Protocol extensions
should be defaults, nothing more.

The rationale mentioned in Swift Evolution for discouraging this behaviour
tends to be that if you conform to the protocol, you should conform and
adhere to all its extensions as well, and that not doing so in the same way
will be inconsistent.

I personally think this comes to the Type-first vs Protocol-first approach
and I think instances of types should have the final say in the behaviour
of the operation. While this would perform slightly worse, and could
potentially be unsafe, I think it is consistent with the fact that not all
implementers of a protocol behave exactly the same; indeed, if they did,
we’d only have one type per protocol, in which case, what is the point of a
protocol at all? Just do it with types.

I love POP and protocol extensions but I’m tempered by the fact that not
all types implement protocols in the same ways, and we can’t predict ahead
of time where those differences will be needed.

On 10 Mar 2017, at 12:48 am, Adrian Zubarev via swift-evolution < > swift-evolution@swift.org> wrote:

My question is why cannot the Base type override the default
implementation? I might want to override it, by calling the default
implementation and modifying the result for my needs.

Something like that:

protocol P {
    func foo() -> Int
}

extension P {
    func foo() -> Int {
        return 42
    }
}

class Base : P {
    override func foo() -> {

        return default.foo() * 100
    }
}

The example is kept simple.

--
Adrian Zubarev
Sent with Airmail

Am 9. März 2017 um 14:37:08, Matthew Johnson via swift-evolution (
swift-evolution@swift.org) schrieb:

Sent from my iPad

On Mar 9, 2017, at 2:23 AM, Slava Pestov via swift-evolution < > swift-evolution@swift.org> wrote:

I think the fact that the type checker permits ‘final’ to appear inside
protocol extensions is an oversight and this probably does not even warrant
a proposal. I don’t think allowing this was ever part of the conceptual
model of protocol extensions at any point in time (if you recall they were
introduced ‘recently’, in Swift 2). If someone put together a PR which
makes ‘final’ in protocol extensions an error in Swift 4 mode (and a
warning in 3), I would merge it.

FWIW that there is one restriction around the direct dispatch here we want
to lift, but it’s not related to this proposal.

If you have a base class conforming to a protocol using default
requirements, eg

  protocol Proto { func f() }
  extension Proto { func f() { } }

  class Base : Proto {}

Currently the witness table for Base : Proto directly references the
extension method Proto.f.

We want to allow this, at least inside the module:

class Derived {
  override func f() {} // does not work currently
}

This will mean that ‘Proto.f’ will appear in the vtable of ‘Base’,
pointing at the extension method. The conformance will dispatch through the
vtable instead of directly calling the extension method.

Would this allow the override to call `Proto.f` through super?

Slava

On Mar 7, 2017, at 7:23 PM, Brian King via swift-evolution < > swift-evolution@swift.org> wrote:

Hey Folks, This draft proposal addresses starter bug SR-1762. I believe
this is in scope for Swift 4 since it impacts source compatibility. It's
not a very exciting proposal, but I think it will help make Swift a little
more consistent.

Remove support for final in protocol extensions · GitHub
[SR-1762] Using "final" keyword in protocol extension doesn't prevent overriding · Issue #44371 · apple/swift · GitHub

Thanks

Brian
Introduction

This proposal suggests removing support for the final keyword when
declaring a function in a protocol extension. The presence of the final keyword
does not currently generate an error message, and it does not actually
modify the dispatch behavior in any way.

<Remove support for final in protocol extensions · GitHub;
Motivation

In the original protocol model of Swift, a developer could use the final keyword
when declaring a function in a protocol extension to ensure the function
could not be overridden. This keyword has no use in Swift's current
protocol model, since functions in protocol extensions can not be
overridden and will always use direct dispatch.

<Remove support for final in protocol extensions · GitHub
design

The compiler should generate an error or warning when the final keyword
is used on a function declaration inside of a protocol extension. This is
consistent with the use of final in structs and enumerations.

<Remove support for final in protocol extensions · GitHub
compatibility

This change will impact source compatibility. To maintain compatibility
with Swift 3, a warning will be generated in Swift 3 mode instead of an
error message.

<Remove support for final in protocol extensions · GitHub
on ABI stability

This has no effect on ABI stability

<Remove support for final in protocol extensions · GitHub
on API resilience

This has no effect on API resilience

<Remove support for final in protocol extensions · GitHub
considered
The only alternative would be to not fix this bug
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution