Re: [swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

2016-04-27 Thread Charles Srstka via swift-evolution
Why would you want lack of an optional method to be a fatal error, either? Charles > On Apr 27, 2016, at 5:29 PM, Andrew Bennett wrote: > > Hi Charles, > > My initial idea just had a fatalError, without a throw. It's better IMO, but > less Swift-y. It's not obvious from the

Re: [swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

2016-04-27 Thread Andrew Bennett via swift-evolution
Hi Charles, My initial idea just had a fatalError, without a throw. It's better IMO, but less Swift-y. It's not obvious from the Swift protocol definition that this could happen. I'm not sure if it's possible for the extension method to have @noreturn or similar on it. On Thursday, 28 April

Re: [swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

2016-04-27 Thread Charles Srstka via swift-evolution
> On Apr 27, 2016, at 9:30 AM, Andrew Bennett via swift-evolution > wrote: > > Sorry if this has been discussed, but have you considered dropping optional > entirely, making it throw, and a default implementation that throws a > selector not found exception? > >

Re: [swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

2016-04-27 Thread James Froggatt via swift-evolution
Interesting idea. I tried this in a playground to see what the calling syntax would be like: let delegate = Optional(Delegate()) let default = 0 let value: Int = (try? delegate?.returnFive() ?? default) ?? default value Not quite as elegant at the call site, but it works. Sadly the rethrowing

Re: [swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

2016-04-27 Thread Andrew Bennett via swift-evolution
Sorry if this has been discussed, but have you considered dropping optional entirely, making it throw, and a default implementation that throws a selector not found exception? This is approximately what you would expect using it in objc. I don't think it has the complexity discussed in the

Re: [swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

2016-04-26 Thread Douglas Gregor via swift-evolution
> On Apr 26, 2016, at 3:33 AM, James Froggatt wrote: > > Fair enough. Upon reflection, I think my real issue is somewhat different to > what I suggested previously. > > I wasn't intending to suggest such a thing would be practical, just that it > would be a decent

Re: [swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

2016-04-26 Thread Zach Waldowski via swift-evolution
Perhaps, with this thought in mind, we should consider making @objc into something more resembling the @available syntax. Getter selector, setter selector, copying, etc. could live there as well. Sincerely,   Zachary Waldowski   z...@waldowski.me On Tue, Apr 26, 2016, at 01:15 AM, Brent

Re: [swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

2016-04-26 Thread James Froggatt via swift-evolution
Fair enough. Upon reflection, I think my real issue is somewhat different to what I suggested previously. I wasn't intending to suggest such a thing would be practical, just that it would be a decent alternative to optional protocol requirements. The alternative given in the proposal seems to

Re: [swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

2016-04-25 Thread Brent Royal-Gordon via swift-evolution
> * What is your evaluation of the proposal? I think this proposed solution doesn't really address the problem. An @objcOptional keyword is intended to make it clear that the feature is fundamentally, intrinsically, for Objective-C compatibility. Separating the keywords doesn't do that;

Re: [swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

2016-04-25 Thread Joe Groff via swift-evolution
I support the approach of making optional requirements ObjC-only. As a nitpick, it feels "wrong" to me to keep a decl modifier around for something that's only a compatibility feature and not natively supported. The proposal notes that a 'objcoptional' modifier was considered and rejected, but

Re: [swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

2016-04-25 Thread Douglas Gregor via swift-evolution
Sent from my iPhone > On Apr 25, 2016, at 12:37 PM, Joe Groff wrote: > > I support the approach of making optional requirements ObjC-only. As a > nitpick, it feels "wrong" to me to keep a decl modifier around for something > that's only a compatibility feature and not

[swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

2016-04-25 Thread James Froggatt via swift-evolution
Eliminating optional protocol requirements is fine by me. The proposal mentions ‘correcting’ the optional protocol requirement pattern by changing the methods to optional closure properties, but my feeling is that this ‘solution’ just acts to continue and perhaps encourage the anti-pattern

[swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

2016-04-25 Thread Chris Lattner via swift-evolution
Hello Swift community, The review of "SE-0070: Make Optional Requirements Objective-C only" begins now and runs through May 2. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0070-optional-requirements.md Reviews are an important part of