I would say that you kind of already entered a slippery slope when the extension to a protocol can add code / not just declare a behavioural contract and how it changes OOP approach (hence: https://bugs.swift.org/plugins/servlet/mobile#issue/SR-302 and https://bugs.swift.org/browse/SR-103 and https://bugs.swift.org/plugins/servlet/mobile#issue/SR-584)
References: https://nomothetis.svbtle.com/the-ghost-of-swift-bugs-future https://www.raizlabs.com/dev/2016/12/swift-method-dispatch Sent from my iPhone > On 5 Nov 2017, at 01:08, Slava Pestov <spes...@apple.com> wrote: > > > >> On Nov 4, 2017, at 1:32 AM, Goffredo Marocchi <pana...@gmail.com> wrote: >> >> >> >> Sent from my iPhone >> >>> On 4 Nov 2017, at 05:26, Slava Pestov via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> Protocols define requirements, they don’t “add” things to the conforming >>> type >> >> I agree with this, but then this warrants a change for protocol extensions >> too. Would you be happy with the restriction that default method >> implementations are only available for value types and not for classes (as >> structs cannot share code any other way, it is the argument for that I seem >> to recall)? > > Protocol extensions are in some sense just syntax sugar for defining new > functions. Having a protocol conformance add storage to the conforming type > is fundamentally different. > > Slava > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
