Oh, to specifically handle ternaries? I hadn't thought of that. That'd be a much more targeted fix. :-)
Jordan
···
On Feb 6, 2017, at 11:46, Daniel Duan <daniel@duan.org> wrote:
On Feb 6, 2017, at 11:35 AM, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@apple.com>> wrote:
On Feb 6, 2017, at 11:08, Daniel Duan <daniel@duan.org <mailto:daniel@duan.org>> wrote:
On Feb 6, 2017, at 10:58 AM, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@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-ternariesI 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?