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.
+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 <swift-evolution@swift.org> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
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).
Are you in control of the XPath strings? If so, you should probably be using `try!`, because any mistake in your queries would be a programmer error.
I'm also not sure why you would call `nodes(forXPath:)` in void context at all—it doesn't have any useful side effects.
···
--
Brent Royal-Gordon
Architechies
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).
Are you in control of the XPath strings? If so, you should probably be using `try!`, because any mistake in your queries would be a programmer error.
I might be, but I've come across XMLs where the XPaths were correct (confirmed), yet the nodes(forXPath:) failed with an error. Mostly when multiple namespaces were present.
I'm also not sure why you would call `nodes(forXPath:)` in void context at all—it doesn't have any useful side effects.
Sorry, this is my fault, kind of got side-tracked since I've recently dealt quite a lot with XML and it was freshly in my mind.
···
On Jun 17, 2016, at 1:20 PM, Brent Royal-Gordon <brent@architechies.com> wrote:
--
Brent Royal-Gordon
Architechies