<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="" applecontenteditable="true"><div class="">I think I see Alex's point here. Optional chaining is still intended to be a substitute for Objective-C's nil-swallowing, and therefore foo?.bar() should not warn if 'bar' has a discardable result, <i class="">even though</i> there is semantic information about whether the method was actually called. I think that of the three things under consideration here:</div><div class=""><br class=""></div><div class="">1. foo?.bar() should not warn</div><div class="">2. foo.map(baz) should warn</div><div class="">3. Ternaries should be consistent with non-ternaries</div><div class=""><br class=""></div><div class="">#1 is the most important, at least to me. The Swift 3 change was to sacrifice #2 in favor of #3, which I'm not sure I would have done, but I wouldn't want to sacrifice #1 in favor of #2.</div><div class=""><br class=""></div><div class="">I wouldn't mind the model of the type being '@discardableResult Optional<Void>' or whatever, but I think that's probably more work than anyone wants to sign up for.</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 31, 2017, at 08:16, Daniel Duan via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Good to know the history. If I were to fix the inconsistency, I'd add the warning to optional chaining instead. <br class=""><br class="">Deliberately make the compiler give us *less* information for esthetic reasons feels wrong to me. As I mentioned in the original email, this has cost us a few unnoticed bad patterns slipping into our production. That's the opposite of what this type of warning is supposed to achieve.<br class=""><br class=""><blockquote type="cite" class="">On Jan 31, 2017, at 1:07 AM, Alex Hoppen <<a href="mailto:alex@ateamer.de" class="">alex@ateamer.de</a>> wrote:<br class=""><br class="">This was a deliberate change between Swift 3 beta 1 and beta 2 after a friend of mine pointed the following inconsistency out to me:<br class=""><br class="">struct Foo {<br class=""> func bar() {}<br class="">}<br class="">let foo: Foo? = Foo()<br class="">foo?.bar() // Does not create a warning<br class="">true ? foo?.bar() : foo?.bar() // expression of type '()?' is unused<br class=""><br class="">After some offline discussion at WWDC with the Swift team we decided to move to a consistent model where ()?, ()??, … is always discardable since we didn't want to take the convenience of foo?.bar() away (something that regularly occurs with weak variables, e.g. captures in closures).<br class=""><br class="">So much for the history of this feature.<br class=""><br class="">– Alex<br class=""><br class=""><br class=""><blockquote type="cite" class="">On 30 Jan 2017, at 22:58, Daniel Duan via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">Hi all,<br class=""><br class="">Right now, expressions that evaluates to Optional<()>, Optional<Optional<()>>… gets special treatment when it’s unused. For example:<br class=""><br class="">func f(s: String) {}<br class="">let s: String = “”<br class="">s.map(f) // no warning here, even tho the resulting type is `Optional<()>` and unused.<br class=""><br class="">func g() throws {}<br class="">try? g() // no warnings here neither.<br class=""><br class="">This is convenient, but encourages composing map/filter/reduce, etc with side-effect-ful functions, which we have found a few cases of in our production code recently. Granted, these cases could’ve been caught with more careful code reviews. But we wouldn’t have missed them if this “feature” didn’t exist.<br class=""><br class="">I think we should remove the special treatment so that code in the example above would generate a warning about `()?` being unused. Users can silence it manually by assigning the result to `_`. <br class=""><br class="">OTOH, this would undermine the convenience of `try?` when the throwing function don’t return anything.<br class=""><br class="">What do y’all think?<br class=""><br class="">Daniel Duan<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></blockquote><br class=""></blockquote><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></body></html>