That is exactly what I was thinking about back then when I posted this idea, but this doesn’t work, at least right now. I’m not sure if this will change if we’ll be forced to use `override` when there is a default implementation provided by the protocol. I’d hope for that behavior. Described here: https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#allowing-subclasses-to-override-requirements-satisfied-by-defaults-
-- Adrian Zubarev Sent with Airmail Am 18. Mai 2016 bei 21:21:40, Sean Heber via swift-evolution ([email protected]) schrieb: 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 > <[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
