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 <cac...@gmail.com> 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 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 2016, Charles Srstka <cocoa...@charlessoft.com > <mailto:cocoa...@charlessoft.com>> wrote: >> On Apr 27, 2016, at 9:30 AM, Andrew Bennett via swift-evolution >> <swift-evolution@swift.org >> <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> 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? >> >> This is approximately what you would expect using it in objc. I don't think >> it has the complexity discussed in the proposals alternatives for other call >> site issues. >> >> If it throws you can call with "try?" to get similar functionality in most >> cases. >> >> This assumes that respondsToSelector doesn't pick up the Swift default >> implementation. > > Is there any case where you’d actually want to display a runtime error as a > result of a delegate not implementing an optional method, though? Even > setting aside that the method’s supposed to be optional, leaving out a needed > delegate method seems more like a programmer error than a runtime error. > > Charles >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
