Hello, I'm aware of all the protocol/extension or multiple protocol options. I think that for the sake of code readability and the ability to easily create components, it is extremely useful. For example, if I want to create a class that has a delegate, it is extremely useful for the caller to easily know what is required to be implemented and what is optional. Having multiple protocols is probably not a great idea, and using the protocol extension method makes it non-intuitive for the caller to clearly understand what is optional. Note that I'm not suggesting a new language constructs, just to ease the requirement on existing one, that honestly, I found extremely clear and making interfaces much more obvious.
-Yuval On Wed, Mar 30, 2016 at 10:18 AM, Haravikk <[email protected]> wrote: > I’m not sure, why not just define an additional protocol with the optional > method(s) you’d like to add? The whole point of protocols is to guarantee > access to some baseline capability, so I’m not sure that optional > capabilities are well covered except by adding new protocols that extend > each other. > > Objective-C conversion has the ability because Objective-C is unusual by > comparison thanks to its ability to have “method calls” (messages) with no > actual destination. I think it’s good for Swift to be more structured and > strict than that. > > > On 30 Mar 2016, at 15:08, Yuval Tal via swift-evolution < > [email protected]> wrote: > > > > Hi, > > > > I find that optional protocol methods to be very useful. However, there > is a caveat -- it needs to be mapped to @objc. This puts a set of > limitations, such as: structures cannot be used as parameters as it does > not map to objective-c. What do you think about removing the requirement of > using @objc and allow to create optional methods without these limitations? > > > > Thank you, > > > > -Yuval >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
