Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 15, 2016, at 5:24 PM, Brent Royal-Gordon > wrote: > >> That’s the other part of my argument: if it is true that Swift code only >> needs to conform to ObjC protocols with optional requirements, but Swift >> code does not need to invoke optional requirements

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 15, 2016, at 4:03 PM, Douglas Gregor wrote: > > Both Joe’s suggestion and my proposal need hackery to do the right thing for > Objective-C interoperability, and both are feasible. I feel like my proposal > is more honest about the hackery going on :) Since there's

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> That’s the other part of my argument: if it is true that Swift code only > needs to conform to ObjC protocols with optional requirements, but Swift code > does not need to invoke optional requirements of ObjC protocols except very > rarely, then it’s okay for calling-an-optional-requirement

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 15, 2016, at 4:27 PM, Matthew Johnson wrote: > > > > Sent from my iPad > > On Apr 15, 2016, at 6:17 PM, Douglas Gregor > wrote: > >> >>> On Apr 15, 2016, at 4:15 PM, Matthew Johnson

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

Sent from my iPad > On Apr 15, 2016, at 6:17 PM, Douglas Gregor wrote: > > >> On Apr 15, 2016, at 4:15 PM, Matthew Johnson wrote: >> >> >> >> Sent from my iPad >> >>> On Apr 15, 2016, at 6:03 PM, Douglas Gregor wrote: >>>

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 15, 2016, at 4:15 PM, Matthew Johnson wrote: > > > > Sent from my iPad > > On Apr 15, 2016, at 6:03 PM, Douglas Gregor > wrote: > >> >>> On Apr 15, 2016, at 3:55 PM, Matthew Johnson

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

Sent from my iPad > On Apr 15, 2016, at 6:03 PM, Douglas Gregor wrote: > > >>> On Apr 15, 2016, at 3:55 PM, Matthew Johnson wrote: >>> >>> On Apr 13, 2016, at 11:42 AM, Douglas Gregor wrote: On Apr 11,

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 15, 2016, at 3:55 PM, Matthew Johnson wrote: > > >> On Apr 13, 2016, at 11:42 AM, Douglas Gregor > > wrote: >> >>> >>> On Apr 11, 2016, at 10:30 AM, Matthew Johnson >>

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 11, 2016, at 12:15 PM, Joe Groff via swift-evolution > wrote: > > To me, compound names for closure properties and satisfying property > requirements with methods aren't hacks, they're missing features we ought to > support anyway. Hello, I may have

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 11, 2016, at 10:30 AM, Matthew Johnson wrote: > > > > Sent from my iPad > >> On Apr 11, 2016, at 12:15 PM, Joe Groff via swift-evolution >> wrote: >> >> >>> On Apr 7, 2016, at 5:12 PM, Douglas Gregor via swift-evolution >>>

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

What about this? I’m unfamiliar with the details of objc-swift interoperability, so I’m not actually sure it could work this way, nor am I certain that I’m not just “rephrasing” something that’s already been suggested. protocol SomeProtocol { //Non-optional stuff goes here } extension

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 11, 2016, at 10:15 AM, Joe Groff wrote: > > >> On Apr 7, 2016, at 5:12 PM, Douglas Gregor via swift-evolution >> wrote: >> >> One could perhaps work around (a), (b), and (d) by allowing compound >> (function-like) names like

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 8, 2016, at 8:53 AM, Shawn Erickson wrote: > > I want to reiterate that I have objective-c code, others have objc code, and > the cocoa, etc. frameworks have code that depend on optional protocol for > things like (but not limited to) delegates. This is of course

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

Inline. > On Apr 11, 2016, at 10:03, Dave Abrahams wrote: > > > on Sun Apr 10 2016, Dietmar Planitzer wrote: > >>> On Apr 10, 2016, at 11:46, Dave Abrahams via swift-evolution >> wrote: >>> >>> >>> on Sun Apr 10 2016, Dietmar Planitzer

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 11, 2016, at 11:41 , Dave Abrahams via swift-evolution > wrote: > > > on Mon Apr 11 2016, Charles Srstka > wrote: > >>On Apr 11, 2016, at 12:03 PM, Dave Abrahams via swift-evolution >>

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

on Mon Apr 11 2016, Charles Srstka wrote: > On Apr 11, 2016, at 12:03 PM, Dave Abrahams via swift-evolution > wrote: > > on Sun Apr 10 2016, Dietmar Planitzer wrote: > > On Apr 10, 2016, at 11:46, Dave Abrahams via swift-evolution > >

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 11, 2016, at 12:03 PM, Dave Abrahams via swift-evolution > wrote: > > on Sun Apr 10 2016, Dietmar Planitzer > wrote: > >>> On Apr 10, 2016, at 11:46, Dave Abrahams via swift-evolution >> wrote: >>>

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

I think we have the following asks: - support methods on a protocol that may or may not be implemented by a confirming type - support statically (per type) detection of whether one of these methods have been implemented so that you can have consistent behavior while interacting with a

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

Sent from my iPad > On Apr 11, 2016, at 12:15 PM, Joe Groff via swift-evolution > wrote: > > >> On Apr 7, 2016, at 5:12 PM, Douglas Gregor via swift-evolution >> wrote: >> >> One could perhaps work around (a), (b), and (d) by allowing

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 7, 2016, at 5:12 PM, Douglas Gregor via swift-evolution > wrote: > > One could perhaps work around (a), (b), and (d) by allowing compound > (function-like) names like tableView(_:viewFor:row:) for properties, and work > around (c) by allowing a method to

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

Sent from my iPad > On Apr 11, 2016, at 12:03 PM, Dave Abrahams via swift-evolution > wrote: > > > on Sun Apr 10 2016, Dietmar Planitzer wrote: > >>> On Apr 10, 2016, at 11:46, Dave Abrahams via swift-evolution >> wrote: >>> >>> >>>

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> And “optional” disappears from the language. Now, there’s no optionality > left, so our useDelegate example tries to just do correct calls: > > func useDelegate(delegate: NSTableViewDelegate) -> NSView? { > let view = delegate.tableView(tableView, viewFor: column, row: row) > let height =

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 10, 2016, at 11:46, Dave Abrahams via swift-evolution > wrote: > > > on Sun Apr 10 2016, Dietmar Planitzer wrote: > >> I’m not sure whether you’ve read the conclusion of my mail since >> you’ve only commented on the introductory

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

on Sun Apr 10 2016, Dietmar Planitzer wrote: > I’m not sure whether you’ve read the conclusion of my mail since > you’ve only commented on the introductory part. In the conclusion I > wrote that a possible approach for the replacement of ObjC-style > optional protocol

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

I’m not sure whether you’ve read the conclusion of my mail since you’ve only commented on the introductory part. In the conclusion I wrote that a possible approach for the replacement of ObjC-style optional protocol methods would be: 1) the default implementation of a protocol method must be

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

I agree, separate protocols is preferable. I think it needs some more thought though, some UIKit protocols have several optional methods, I'm not sure if a protocol for each would be very clean. The other thing that needs consideration is whether it's possible to automatically convert objc with

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> Le 8 avr. 2016 à 14:47, Jonathan Hull via swift-evolution > a écrit : > > Interesting proposal, but I wanted to mention a couple of potential issues > off the top of my head. I know when I was using optional requirements in > Objective C, I would often use the

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

In this case, I would think you would move the optional method into a separate protocol. If the user implemented the method they would have to explicitly conform to this specific protocol in which case they would be treated differently. Instead of having to check whether someone implemented

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

For a while I've thought it would be useful to have a way to refer to the protocol's default implementation, even when you provide your own. We could possibly do away with most people's concerns and optional methods if we could do something like this: if MyProtocol.someMethod === Self.someMethod

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

Thanks for the excellent writeup and thought on this. I strongly believe - as a protocol adaptor - that having the ability to know if a default implementation is provided in the interface I see. It would also be helpful if documentation (header docs) about the characteristics of the default

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

The biggest missing part with this model is that we are still not able to enable macro-level optimizations in the delegating type by checking whether the delegate does provide his own implementation of an optional method or doesn’t. However, this is an important advantage of the ObjC model that

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

My main point was that, this was an extremely common practice in Objective C (one which was even used/encouraged by Apple for quite a while) and the proposal needs to address it. There is a lot of working code out there that uses this pattern. In short, we need to be careful not to

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

I want to reiterate that I have objective-c code, others have objc code, and the cocoa, etc. frameworks have code that depend on optional protocol for things like (but not limited to) delegates. This is of course obvious but what seems to get lost in the discussion is that you can't always replace

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

Table view semantics were discussed at length on a prior version of the thread. That pattern is less than ideal; it essentially creates magic behavior that's only described by documentation… or, worse, completely forgotten about in documentation; something changing from version to version of the

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

Proposal sounds nice, but shouldn't it go hand in hand with the review of dispatching rules for protocol extensions (i.e.: dynamic dispatch by default unless overridden by a user declaration/annotation or when the compiler is sure no side effects will occur... ProtocolA and

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 7, 2016, at 6:12 PM, Douglas Gregor via swift-evolution > wrote: > With my proposal, we’d have some compiler-synthesized attribute (let’s call > it @__caller_default_implementation) that gets places on Objective-C optional > requirements when they get

[swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

Hi all, Optional protocol requirements in Swift have the restriction that they only work in @objc protocols, a topic that’s come up a number of times