[swift-evolution] Proposal: Finalization in protocol extensions and default implementations
Sean Heber
sean at fifthace.com
Wed May 18 14:21:29 CDT 2016
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.
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
More information about the swift-evolution
mailing list