> On Feb 6, 2017, at 11:46, Daniel Duan <dan...@duan.org> wrote: > >> >> On Feb 6, 2017, at 11:35 AM, Jordan Rose <jordan_r...@apple.com >> <mailto:jordan_r...@apple.com>> wrote: >> >>> >>> On Feb 6, 2017, at 11:08, Daniel Duan <dan...@duan.org >>> <mailto:dan...@duan.org>> wrote: >>> >>> >>>> On Feb 6, 2017, at 10:58 AM, Jordan Rose <jordan_r...@apple.com >>>> <mailto: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* >> >> I suspect this will entail making a new sugared type kind and then threading >> it carefully through the constraint solver (hence why I said it's probably >> more work than you want to take on). >> > > I was going to write a enhanced version of > TypeBase::lookThroughAllAnyOptionalTypes(). Too hacky?
Oh, to specifically handle ternaries? I hadn't thought of that. That'd be a much more targeted fix. :-) Jordan
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
