Just tried to enable generation of `if let` statements for binary expressions and got the following result, which compiles without issues:
Currently, we do not generate `if let` statements for this case for 2 reasons:
1) Unwrapped arguments (i.e. `touch1?.x`) have an primitive type (CGFloat), thus we resort to using `??` operator;
2) Unwrapping using `if let` statements was not enabled for binary expressions.
I am fine to enable `if let` statements for binary expressions (2).
However, I am still in doubt about using `if let` statements to unwrap expressions of primitive types such as Int, Float or String (compared to using `??` operator as implemented now).
To compare, here is how the first function from the default code sample on our website looks after I disable checks (1) and (2) above:
What do you think about cases like above (unwrapping primitive type binary expression operands) - should we switch from `??` operator to `if let` for these cases?
The compiler issue seems very well known:
Of course, we can make this a configurable option later, but as I mentioned, this multiplies the amount of testing so I am yet targetting to produce the single, best possible output.
The problem here is due to an immature compiler (struggling with complex expressions), as opposed to syntax errors (which are the usual bug fixes that we need to do).
Following this approach to fix this creates 2 issues, in my opinion:
1. The `if let` simply doesn't read as nicely as the nil-coalescing operator in many examples
2. Wrapping it in an `if let` could actually create more compilation errors than it solves
Regarding #2, in the example you gave from the default code sample, `plane` is now an Optional<SCNPlane> where it was previously a non-optional SCNPlane. Should we be worried about this causing compilation issues in larger functions?
From the little bit of context I've seen in this ticket, I'd suggest leaving things as they are. I wouldn't want to negatively change how we convert these expressions 100% of the time, just for the small chance that the expression may be too complex for the Swift compiler.
I agree with your suggestion to treat this as a lower priority and leave the things "as is" for now.
Still wanted to pass this through you since
(1) This compiler bug has started to happen only after I've implemented unwrapping with `??` operator (), and
(2) I've noticed this same issue with 2 different projects, during 2 consecutive days
(while I was analyzing the impact of the recent changes in the error rate with actual projects).
in the example you gave from the default code sample, `plane` is now an Optional<SCNPlane> where it was previously a non-optional SCNPlane. Should we be worried about this causing compilation issues in larger functions?
If we use an `if let` statement, we also treat the `plane` variable as optional in our converter.
As you see, the further code is correctly unwrapping the variable:
So, in short, we already do a decent job when unwrapping optionals, although there are few more related scheduled improvements.
If still we ever want to address this JIRA issue, my current "best guess" is unwrapping only non-trivial expressions (i.e., everything but a single identifier or property/message expression) using `if let` statements.
Related: after upgrading to Xcode 10.2 beta 2, I got 3 "The compiler is unable to type-check this expression in reasonable time" errors in the Tip Tap Too project:
The failing code looks like follows: