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]> 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]> 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
