> On May 18, 2016, at 2:21 PM, Sean Heber via swift-evolution 
> <[email protected]> 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 
>> <[email protected]> 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
>> <[email protected]> wrote:
>>> 
>>> On May 18, 2016, at 12:53 PM, Adrian Zubarev via swift-evolution
>>> <[email protected]> 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
>>> ([email protected]) 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
>>> [email protected]
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected]
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to