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

[Matthew Johnson]

> 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 <mailto: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 <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160518/46577451/attachment.html>