Hi James, I don't think it would complicate it any more than a throw normal is. You can still use a do/catch, with types catches.
On Thursday, 28 April 2016, James Froggatt <[email protected]> wrote: > 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 > overload of ?? complicates things, I'm not sure of a way to work around > that directly. > > I do like that types could potentially implement the function and do > something, then throw an error rather than returning a value, which would > allow them opt into using the default value. It would complicate matters if > the conforming types throw multiple errors for whatever reason, though. > > From James F > > On 27 Apr 2016, at 15:30, Andrew Bennett <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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. > > On Wednesday, 27 April 2016, James Froggatt via swift-evolution < > [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> Thanks again. >> >> I had a look at the links in the proposal as you suggested, and I see a >> lot of people pointing to protocol extensions as a solution (and >> counter-arguments of the inability to optimise code with this method, which >> are left unresolved). >> >> To make use of the protocol extensions solution, one would have to define >> the protocol, add a protocol extension which implements every function, >> then add an empty type which allows access to these implementations. >> For a recommended alternative, this seems a lot of work. In a world where >> Swift didn't have Objective C compatibility, and this empty-type workaround >> to access defaults was the best option available, I'd be inclined to >> support a proposal to add optional method requirements. It has the added >> optimisation and easy delegate-swapping relative to closure properties, as >> you mentioned, and feels less hacky than the closure-function switching >> suggested in the proposal. >> >> The protocol extension + default type would provide a direct alternative, >> but it leads me to wonder what exactly we're trying to avoid by >> discouraging optional methods. The potential for unexpected optimisation, >> which seems to be the primary issue, is unsolved, since the type can check >> to see if the delegate is its own, default type, and proceed to ignore the >> method regardless. In exchange, we make things much harder for types simply >> wishing to have a default value when there is no registered delegate. >> >> So what aspect of optional protocol requirements are we actually trying >> to discourage, which isn't present in protocol extensions? >> >> PS. If we're concerned about overlap with protocol extensions: it seems a >> bit like eliminating functions from the language because they overlap with >> the more general concept of closures. It's a fine idea, but it seems more >> reasonable to find a solution that handles both cases conveniently before >> we start eliminating one of them. >> >> From James F >> >> > On 26 Apr 2016, at 22:56, Douglas Gregor <[email protected]> wrote: >> > >> > >> >> On Apr 26, 2016, at 3:33 AM, James Froggatt <[email protected]> >> 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 alternative to optional protocol requirements. >> The alternative given in the proposal seems to be more of a way to remove >> optional protocol requirements on the surface, while actually helping to >> make them a native feature, if you see what I mean. It's not a realistic >> alternative - it's a worse syntax for the exact same thing, which also >> comes with awful side-effects for Swift as a whole. No-one would ever >> seriously consider this as an alternative, yet it's listed as under the >> heading ‘Alternatives Considered’. >> > >> > If you follow the swift-evolution discussion links in the proposal, >> you’ll note that a number of people have proposed exactly what is listed in >> “Alternatives Considered”. The only truly wacky idea in there is my >> caller-side default implementations idea, which I covered simply because it >> was my last stab at eliminating optional requirements before giving up and >> sequestering them permanently behind “@objc”. >> > >> >> >> >> You say the arguments given against optional closure properties are >> strong, but I don't they would be nearly as relevant to the case I >> suggested. By making them properties of the table view, the tableView >> parameter would be eliminated, meaning the property names could be unique. >> >> >> >> EG: >> >> var numberOfRows: (inSection: Int) -> Int >> >> var cellForRow:: (at: NSIndexPath) -> UITableViewCell >> >> var moveRow: (from: NSIndexPath, to: NSIndexPath) >> >> >> >> This removes the need to add the mentioned workarounds, since a >> function could be assigned to the closure property just as easily as an >> inline closure. I feel this is much more worthy of being considered as an >> alternative. The idea of these proposals is to document why we do things, >> so at least for someone wondering why we require all this @objc syntax >> rather than support optional protocol requirements natively, this would >> actually present them with a viable alternative which could be applied in >> their APIs. >> > >> > Doing this implies creating a potentially large number of stored >> closure properties, which is not as storage-efficient as storing a single >> delegate reference. Moreover, it makes it harder to set up your >> customization points: instead of implementing one protocol, you’re writing >> assignments into some number of stored closure properties. Imaging trying >> to change the delegate to some other delegate temporarily: you would have >> to manually store each of the closures into some local structure and >> introduce your own, except that you can’t get them all because some new >> version of the platform would add new stored closure properties. Finally, >> Cocoa just doesn’t work like this, so you would require some massive >> re-architecture to get there. I don’t see how this is a better design. >> > >> > - Doug >> > >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
