[swift-evolution] Proposal: Finalization in protocol extensions and default implementations

[Matthew Johnson]

> On May 18, 2016, at 2:21 PM, Sean Heber via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Putting “final” on a default method implementation that is inside of a protocol extension could maybe make some sense to prevent other implementations of that method, but final in the protocol itself doesn’t make sense to me.

It makes sense until you consider retroactive modeling.  When you do that it becomes unclear whether the two are compatible and retroactive modeling is far more important.

> 
> l8r
> Sean
> 
> 
>> On May 18, 2016, at 2:18 PM, Leonardo Pessoa via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Adrian, what would be the meaning of this final declaration? In my
>> understanding, a final means there can be no more overrides of that
>> method but there are no implementations in a protocol so I really
>> don't understand this use.
>> 
>> On 18 May 2016 at 16:15, Matthew Johnson via swift-evolution
>> <swift-evolution at swift.org> wrote:
>>> 
>>> On May 18, 2016, at 12:53 PM, Adrian Zubarev via swift-evolution
>>> <swift-evolution at swift.org> wrote:
>>> 
>>> I’d like to revive this idea I posted long time ago. There is only one thing
>>> I need to update here:
>>> 
>>> protocol MagicType: class /* missed the class constraint */ {
>>> 
>>>   final var foo: Int { get }
>>>   final func boo()
>>> }
>>> 
>>> What benefit is there in defining a protocol requirement as final?
>>> 
>>> What do you guys think? Is there any technical reason why this is not
>>> possible?
>>> 
>>> --
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 5. Dezember 2015 bei 16:26:23, Adrian Zubarev
>>> (adrian.zubarev at devandartist.com) schrieb:
>>> 
>>> Hello there,
>>> 
>>> I wonder if it is a good idea to be able to finalize in protocols and
>>> default implementations.
>>> 
>>> Here is an example:
>>> 
>>> protocol MagicType {
>>> 
>>>   final var foo: Int { get }
>>>   final func boo()
>>> }
>>> 
>>> class X: MagicType {
>>> 
>>>   final var foo: Int {
>>> 
>>>       return 42
>>>   }
>>> 
>>>   final func boo() {
>>> 
>>>       print("magic")
>>>   }
>>> }
>>> 
>>> class Y: X {
>>> 
>>>   // can't override func boo or var foo in here
>>> }
>>> 
>>> //===================================================//
>>> 
>>> protocol SomeType {}
>>> 
>>> extension SomeType {
>>> 
>>>   final func foo() {
>>> 
>>>       print("Hello World")
>>>   }
>>> }
>>> 
>>> class A: SomeType {}
>>> 
>>> class B: SomeType {
>>> 
>>>   /* this should raise an error, because the class B shouldn't */
>>>   /* be able to override that function from SomeType */
>>> 
>>>   func foo() {
>>>       // do something else
>>>   }
>>> }
>>> 
>>> How do you anticipate this would interact with retroactive modeling of types
>>> which would conform the requirements of `SomeType` but also happen to have a
>>> `foo` method?
>>> 
>>> 
>>> 
>>> —
>>> Regards Adrian
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> 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
>>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> 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