> On Feb 6, 2017, at 10:58 AM, Jordan Rose <jordan_r...@apple.com> wrote: > > 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, even though there is semantic > information about whether the method was actually called. I think that of the > three things under consideration here: > > 1. foo?.bar() should not warn > 2. foo.map(baz) should warn > 3. Ternaries should be consistent with non-ternaries >
I 100% agree with this analysis. > #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. > > 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. I’ll give this a go and report back. *crosses fingers* > > Jordan > > >> On Jan 31, 2017, at 08:16, Daniel Duan via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Good to know the history. If I were to fix the inconsistency, I'd add the >> warning to optional chaining instead. >> >> 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. >> >>> On Jan 31, 2017, at 1:07 AM, Alex Hoppen <a...@ateamer.de >>> <mailto:a...@ateamer.de>> wrote: >>> >>> 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: >>> >>> struct Foo { >>> func bar() {} >>> } >>> let foo: Foo? = Foo() >>> foo?.bar() // Does not create a warning >>> true ? foo?.bar() : foo?.bar() // expression of type '()?' is unused >>> >>> 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). >>> >>> So much for the history of this feature. >>> >>> – Alex >>> >>> >>>> On 30 Jan 2017, at 22:58, Daniel Duan via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> >>>> Hi all, >>>> >>>> Right now, expressions that evaluates to Optional<()>, >>>> Optional<Optional<()>>… gets special treatment when it’s unused. For >>>> example: >>>> >>>> func f(s: String) {} >>>> let s: String = “” >>>> s.map(f) // no warning here, even tho the resulting type is `Optional<()>` >>>> and unused. >>>> >>>> func g() throws {} >>>> try? g() // no warnings here neither. >>>> >>>> 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. >>>> >>>> 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 `_`. >>>> >>>> OTOH, this would undermine the convenience of `try?` when the throwing >>>> function don’t return anything. >>>> >>>> What do y’all think? >>>> >>>> Daniel Duan >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
