+1. The required _ = try? on what used to be a BOOL result in ObjC is incredibly annoying, mostly with NSXML* classes on OS X where you really don't care about the error 99% of the time, but care just about the result (nodesForXPath, etc).
> On Jun 17, 2016, at 1:04 PM, Jonathan Cotton via swift-evolution > <[email protected]> wrote: > > I propose that the compiler warnings for unused results are removed from try? > if the statement being ‘tried’ does not return itself. This is inline with > how try works and although try? does have a possible return value itself > (nil) the warning isn’t adding/helping any if the result is either going to > be nil or void. > > When try? is used in this way, it is essentially the caller saying they don’t > care if the operation fails and any consequences of that failure will be > handled later on. > > I have a slightly contrived example here on gist of where this could be > useful https://gist.github.com/joncottonskyuk/abc6caad8be137193d4e1e58cc8d2e06 > > basically, in the person model, I don’t always care if the emailAddress is > set, but in some cases I do, to differentiate between the two use cases, the > caller can choose to use either try when they do care and want to handle the > specific error, or try? if they don’t care about the failure and just want to > carry on with the usual execution path. > > The alternative is to just leave this as it is and the caller must then use _ > = try? … to suppress the warnings. However, whilst _ = is very useful for > suppressing this warning in most cases, as it shows intent for future > maintainers of the code, in this case I don’t think it really adds any value. > If the statement being attempted does not return itself then you are left > with no choice but to assign to nothing to suppress the warning as opposed to > assigning to some local reference and then just throwing that away. > _______________________________________________ > 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
