@DougGregor or @milseman, I thought we were marking imported functions with @discardableResult? Is it the optional binding that's throwing that off?

We are marking imported functions with `@discardableResult` by default. You're probably right about the optional binding.

@DougGregor try? might be another example. So, for instance:

try? AVAudioSession.sharedInstance().setActive(true)

That warns, but I'm not clear on whether it should. Again, it's not a problem, as I know how to silence the warning, but it seems unnecessary, as the whole point of try? is to say, Hey, if it works it works and if it doesn't it doesn't.

@DougGregor Here's one that doesn't involve any optional binding:

        var options = NSStringCompareOptions.caseInsensitiveSearch
        options.insert(.anchoredSearch) // warns

That latest is different; it's just a place where the standard library needs @discardableResult added. Can you file a separate bug for that?

I'm okay with try? because it's just translating the error (which you must handle) to an Optional (which you should handle). An extra step to say "and I'm ignoring it" seems fair.

@belkadan Excellent, thanks on both points. Perfectly reasonable, just checking. — Separate bug is SR-1695.

Comment by Eric (JIRA)

I think the default for @warn_unused_result was flipped, but I can't find much except for this: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003527.html

I think we just need a way to annotate that it the ignored return value is intentional, either at the call site or the method definition. Maybe both.

EDIT: just noticed @discardableResult in the comments tab. Excellent!

I think this is a language bug, not a lib issue. Here’s a self-contained case to reproduce (as of XC 8b6):

extension Int {
    @discardableResult
    public func foo() -> Int { return self }

    @discardableResult
    public func bar() -> Int? { return self }
}

func foo() {
    let x: Int? = 3

    x?.bar() // incorrect warning

    x!.bar() // no warning
    x?.foo() // no warning
}

(Note that this is not a dup of SR-1929, which does indeed appear to be fixed.)

Comment by Tim Bodeit (JIRA)

See #4625

Thanks @pcantrell, your example helped a lot.

timbodeit (JIRA User) Sure thing. I’m glad it was useful!

Comment by Fabian Ehrentraud (JIRA)

This bug is still present in Xcode 8 GM, right?

I'd like to reopen this issue. It is not fixed in my copy of Xcode 8.

self.navigationController!.popViewController(animated:true)

does not warn, but

self.navigationController?.popViewController(animated:true)

does warn. I regard that as a bug.

The fix did not make it into Xcode 8 (or 8.1, which is mostly taking targeted fixes).

OK, thanks @belkadan.

Should this fix be in Xcode 8.1 beta 3?

Comment by Tim Bodeit (JIRA)

@keith No, as @belkadan pointed out, this fix will not be a part of Xcode 8.1.
The GitHub page of the commit lists branches and tags containing this commit. So far it has only been included in development snapshots. As far as I can tell, Xcode and its betas are based on the `swift release` and `swift preview` tags. c97ebb0

I saw that comment, but I was hoping to clarify whether or not fixes like this would make it in to subsequent Xcode betas.

Comment by Michael Taverne (JIRA)

I'm still seeing this issue in Xcode 8.2.1. Should it have been resolved in this version?

No, sorry, Xcode 8.2 only contained minor updates to Xcode 8.1, not a rebranch from master. It will be resolved in Xcode 8.3 with Swift 3.1.

@belkadan Thanks so much for clarifying. Truly appreciated.