Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

> On Apr 1, 2016, at 5:37 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> Protocol requirements with default (no-op) implementations already satisfy >> that design goal, no? > > Kind of. If I may steelman* optional members for a moment... > > In cases

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

> On Apr 3, 2016, at 10:21 PM, Thorsten Seitz via swift-evolution > wrote: > > As the problem seems to be to eliminate having to write the extension with > all its duplication, I'd prefer a more general solution instead of > introducing the notion of an "optional"

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

> I'd prefer a more general solution instead of introducing the notion of an > "optional" function: just make it possible to write default implementations > inline in a protocol definition. This would work, too. I guess there's no need for an “optional” keyword if the implementation is right

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

As the problem seems to be to eliminate having to write the extension with all its duplication, I'd prefer a more general solution instead of introducing the notion of an "optional" function: just make it possible to write default implementations inline in a protocol definition. Documenting

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

I understand the concern. To me, the answer is clearly yes. The language cannot be considered in isolation from its use cases; imagine UIKit written in Swift. You want the developers to be able to quickly understand which table view delegate methods they need to implement, and what the

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

For readability and specifically in this case, I think it does make sense IMHO. On Sunday, April 3, 2016, Chris Lattner wrote: > > On Apr 3, 2016, at 10:40 AM, Andrey Tarantsov > wrote: > >

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

> On Apr 3, 2016, at 10:40 AM, Andrey Tarantsov wrote: > >> Protocol requirements with default (no-op) implementations already satisfy >> that design goal, no? > > Chris, as we've discussed in a thread that I think got forked from this one: > > Yes, they do technically,

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

> Protocol requirements with default (no-op) implementations already satisfy > that design goal, no? Chris, as we've discussed in a thread that I think got forked from this one: Yes, they do technically, but it would be nice to both: 1) make it an obvious documented part of the signature,

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

>> I've actually had multiple cases in Objective-C code where this feature >> (some object behaving differently depending on wether or not a delegate >> method has been implemented) has prevented me from implementing features the >> easy and obvious way. In those cases I resorted to

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

> I do not understand why an optional method should require a default value. > That’s not how optional methods work in Objective-C where the caller will ask > whether the method is implemented and calls it or does something else. With a > default value it would be much more difficult to do

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

> Some ideas I was thinking about for optional protocol functions was you’d > declare it like this: > > protocol UIGestureRecognizerDelegate { > optional func gestureRecognizerShouldBegin(gestureRecognizer: > UIGestureRecognizer) -> Bool = true > } > > If you put “optional” there, the

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

> On Apr 1, 2016, at 7:37 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> Protocol requirements with default (no-op) implementations already satisfy >> that design goal, no? > > Kind of. If I may steelman* optional members for a moment… I’d actually go a

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

Sent from my iPad > On Apr 2, 2016, at 7:04 AM, Lukas Stabe via swift-evolution > wrote: > > All use-cases I had for optional methods in protocols in Objective-C are > covered nicely by providing a default implementation in a protocol extension, > so I don't

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

All use-cases I had for optional methods in protocols in Objective-C are covered nicely by providing a default implementation in a protocol extension, so I don't think optional protocol methods should be a thing in pure Swift. > I do not understand why an optional method should require a

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

Very good points Dietmar, but there is one more bit about default implementations in extensions that makes it worse to use than the old Objective-C model... the complex dispatch rules that can make the executed method type dependent and not instance dependent. We really need dynamic dispatch

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

> > > class UITableView { > ... > private func addRow(at indexPath: NSIndexPath) { > ... > cell.size.height = delegate?.tableView(self, > heightForRowAtIndexPath: indexPath) ?? rowHeight >

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

-1 I hope that default implementations living in the protocol will address this. I would even prefer to move in 'the other direction' and have optional methods on protocols come into swift as default implementations. TJ On Sat, Apr 2, 2016 at 6:07 AM, Brent Royal-Gordon via swift-evolution <

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

> Protocol requirements with default (no-op) implementations already satisfy > that design goal, no? Kind of. If I may steelman* optional members for a moment... In cases where a default implementation would do, the default implementation will usually also be the behavior you want for a nil

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

Good point. That would obviously restrict the choice for naming the methods in such a protocol, but since we are talking about new protocols that would not be an impediment. It might result in non-optimal method names, of course. -Thorsten > Am 31.03.2016 um 18:37 schrieb Rob Mayoff via

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

>> None taken. However, most of the delegate concept of UIKit relies heavily on >> this "nonsensical" requirement. It is impossible for someone to implement a >> control in swift which is "in the spirit" of UIKit, meaning the control has >> a delegate, with several methods that share the same

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

> On 31 mars 2016, at 22:01, Chris Lattner via swift-evolution > wrote: > > Protocol requirements with default (no-op) implementations already satisfy > that design goal, no? They do, but that is not clear for everyone. And after protocol extensions appeared with

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

> On Mar 31, 2016, at 11:49 AM, Yuval Tal via swift-evolution > wrote: > > None taken. However, most of the delegate concept of UIKit relies heavily on > this "nonsensical" requirement. It is impossible for someone to implement a > control in swift which is "in the

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

> On Mar 31, 2016, at 5:51 PM, David Waite via swift-evolution > wrote: > > +1 > > We need to support optional methods in @objc protocols because it is required > for interoperability. However, there are in my experience only reasons for an > optional protocol

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

+1 We need to support optional methods in @objc protocols because it is required for interoperability. However, there are in my experience only reasons for an optional protocol method: - There is a very common default behavior for a delegate (such as return immediately with a value of

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

To be fair, the "spirit of UIKit" that you mention comes from a time and language that encouraged OO and OO alone. Optional methods are, more often than not, backed by gigantic bit fields that keep track of whether or not the delegate actually conforms to the entirety of a protocol, which

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

> Caveat: this is going to be strongly-worded; sorry in advance. I think > (no offense intended) it's a terrible idea. The whole notion of an > “optional requirement” is nonsensical to begin with, and the use of > optional protocol requirements encourages a style of programming that > lifts the

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

None taken. However, most of the delegate concept of UIKit relies heavily on this "nonsensical" requirement. It is impossible for someone to implement a control in swift which is "in the spirit" of UIKit, meaning the control has a delegate, with several methods that share the same name with

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

on Wed Mar 30 2016, Yuval Tal 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

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

Some ideas I was thinking about for optional protocol functions was you’d declare it like this: protocol UIGestureRecognizerDelegate { optional func gestureRecognizerShouldBegin(gestureRecognizer: UIGestureRecognizer) -> Bool = true } If you put “optional” there, the compiler would

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

I'm missing those optional methods too, but protocol extensions sound like a better solution for this. (For those suggesting a separate protocol, consider UITableView. How many protocols would it take to model all the optional delegate methods as separate protocols? Certainly more than 10,

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

Another alternative is to add a protocol extension with blank/harmless/default methods for things that are optional and always call 'em. On Wed, Mar 30, 2016 at 7:18 AM, Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > I’m not sure, why not just define an additional protocol

[swift-evolution] [Proposal] Make optional protocol methods first class citizens

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